Elicpse CDT думает, что он сломан - PullRequest
Новая
       32

Elicpse CDT думает, что он сломан

3 голосов
/ 24 октября 2009

Я использую Eclipse для некоторых встроенных разработок и недавно начал сообщать мне об этих ошибках каждый раз, когда я сохраняю файл или делаю сборку. Это раздражает, но по большей части, похоже, не вызывает каких-либо проблем (даже выделяет предупреждения / ошибки в источнике. Что здесь происходит? 

Plug-in org.eclipse.cdt.cross.arm.gnu was unable to load class 
org.eclipse.cdt.managedbuilder.internal.scannerconfig.DefaultGnuWinScannerInfoCollector.

Plug-in org.eclipse.cdt.cross.arm.gnu was unable to load class  
org.eclipse.cdt.managedbuilder.internal.scannerconfig.ManagedGCCScannerInfoConsoleParser

Ответы [ 2 ]

1 голос
/ 24 октября 2009

Похоже, что в eclipse wiki говорится, что

Наиболее вероятная причина в том, что в статическом инициализаторе было сгенерировано исключение для класса, объявленного нарушающим плагином. Проверьте файл .log, чтобы увидеть, действительно ли это произошло.
Загрузчик платформы Eclipse не будет загружать плагин, когда возникают исключения во время инициализации классов Java, которые составляют плагин.

Другая распространенная причина этой ошибки - отсутствие подходящего конструктора для загружаемого класса. Большинство классов, объявленных в точках расширения, должны иметь открытый конструктор с нулевым аргументом. Обратитесь к документации по точке расширения, чтобы узнать, какой конструктор необходим для классов, которые вы объявляете в расширении.

Если проблема возникает только при развертывании упакованного плагина (т. Е. Когда он не запускается в рабочей среде времени выполнения через PDE), обычно рекомендуется проверить атрибут Bundle-ClassPath в файле MANIFEST.MF.
Файл JAR, содержащий подключаемые классы, должен быть указан в Bundle-ClassPath. Даже если все надлежащие классы плагина перечислены в списке, загрузка классов все равно может завершиться неудачей, поскольку файл .class может содержать ссылки на другие классы, которые не могут быть разрешены во время выполнения. В этом случае недостающие классы должны быть идентифицированы (обычно путем просмотра операторов импорта проблемного класса) и необходимые записи должны быть добавлены в Bundle-ClassPath. Если требуются дополнительные JAR-файлы, эти JAR-файлы также должны быть перечислены в файле build.properties, чтобы они включались при упаковке подключаемого модуля.

(см. эту тему в качестве иллюстрации этой последней точки)

Так, например, в этой теме , для другой проблемы в eclipse3.0 time:

Файл plugin.xml определяет "org.eclipse.core.runtime.compatablity" как обязательный плагин. Однако я использую Eclipse версии 3.0.1 и должен использовать "org.eclipse.core.runtime_3.0.1".

Решение:

Заменить строку в Plugin.xml 

<import plugin="org.eclipse.core.runtime.compatability"/>

с 

<import plugin="org.eclipse.core.runtime"/>
0 голосов
/ 12 декабря 2009

VonC прав - достаточно подробно о том, что может пойти не так с загрузкой классов ...

В этом случае ваша цепочка инструментов arm.cross ссылается на внутренние классы в управляемой сборке CDT, которые недоступны. Это несовместимость между вашим набором инструментов и CDT. Вы должны сообщить им об этой ошибке, сначала попробовав более новую версию.

...