Как добавить обычный банку в плагин (ClassNotFoundException, NoClassDefFoundError)?

Question

Я использую сторонний код, который использует некоторую банку (на самом деле это log4j). При запуске моего плагина я получаю несколько ошибок ClassNotFoundException, NoClassDefFoundError. Поскольку использование стороннего кода ограничено только ViewPart, программа запускается, но представление не создается.

Во время компиляции в Eclipse я добавил необходимые банки в класс, как обычно, и код не имеет ошибок во время компиляции, включая import директивы для log4j.

Так как я положил все (многие) необходимые банки в lib подкаталоге моего каталога проекта, я думал изменить build.properties ниже

source.. = src/ 
output.. = bin/ 
bin.includes = plugin.xml,\ 
       META-INF/,\ 
       lib/,\ 
       . 

Но, видимо, это не помогло.

Где я могу увидеть весь собранный пакет/плагин, скомпилированный для проверки, какие банки там содержатся?

UPDATE

В настоящее время я положить необходимые банки дважды.

Первый один - в обычный Eclipse, Configure Build Path окна:

второй - в Classpath раздел Runtime вкладки plugin.xml редакторов:

последней конфигурация делает следующее изменение в build.properties файла:

source.. = src/ 
output.. = bin/ 
bin.includes = plugin.xml,\ 
       META-INF/,\ 
       lib/,\ 
       .,\ 
       lib/java-getopt-1.0.13.jar,\ 
       lib/jsp-api-2.0.jar,\ 
       lib/junit-4.11.jar,\ 
       lib/log4j-1.2.17.jar,\ 
       lib/rhino-1.7R4.jar,\ 
       lib/servlet-api-6.0.36.jar,\ 
       lib/tomcat-catalina-7.0.42.jar,\ 
       lib/commons-logging-1.1.3.jar,\ 
       lib/spring-beans-3.2.0.RELEASE.jar,\ 
       lib/spring-core-3.2.0.RELEASE.jar,\ 
       lib/miglayout-core-4.2.jar,\ 
       lib/miglayout-swt-4.2.jar,\ 
       conf/ 

Возможно ли это AUTOMATE это как-то? Можно ли АВТОМАТИЧЕСКИ передать все обычные записи в пути к runtime?

Мне нужно УПРОЩЕНИЕ, я не хочу обертывать банки в пучки и что-то подобное.

Вопрос открылся.

Answer 1

Чтобы экспортировать плагин, вы можете использовать меню «Файл» -> «Экспорт» -> «Разработка плагинов/развертываемые плагины и фрагменты». Затем выберите плагин, и он будет экспортирован как банку. Для экспорта продукта существует опция экспорта продукта в файл .product.

Я предлагаю вам создать отдельный подключаемый модуль с помощью опции «Plug-in from existing JAR archives» в мастере «Новый проект». Если да, то, надеюсь, вы не забыли включить его в свою конфигурацию запуска. Также, пожалуйста, уточните this question.

Update: Вы не требуется ни, ни вынуждены конвертировать ваши банки в пучках, но так как ваш не создавая чистый проект Java (у вас есть OSGi расслоения, со своим собственным загрузчиком классов и жизненного цикла), вы можете хотите принять во внимание некоторые лучшие практики/правила, которые могут помочь вам создать хороший плагин/проект.

Почему вам нужно преобразовать зависимости в пакеты?

У вас уже есть своя зависимость третьей стороны (log4j, Apache Commons коллекция и т.д.,), как банки и все, что вам нужно сделать, это добавить его в расслоения классов. Это просто и работает до тех пор, пока вы работаете , разрабатывая только один пакет или ваши пакеты не имеют общих зависимостей.

Но, на самом деле, вы можете создать кучу пучков, и все они будут использовать общие зависимости. Проблема здесь в том, что работает надстройка классов OSGi . Каждый пакет имеет свой собственный загрузчик классов, и поэтому, если у вас есть два пакета, которые используют log4j как зависимость jar в своем пути к классам , и когда вы пытаетесь ссылаться на log4j в каждом из пакетов, каждый попытается создать свои собственные экземпляры классов log4j в их соответствующих загрузчиков классов. Это может привести к ограничениям класса loader нарушениям или ClassCastExceptions. Если вы преобразуете эти зависимости в пакеты OSGi, тогда эти проблемы больше не будут . Это связано с тем, что теперь каждая из ваших зависимостей (скажем, log4j) имеет - это собственный загрузчик классов, поэтому всякий раз, когда ваш Bundle A или Bundle B хочет загрузить log4j class, он загрузит его из загрузчика классов log4j.

Для получения дополнительной информации обратитесь к this article.

Относительно процесса автоматизации: Я не думаю, что это возможно. Поскольку вы вручную добавляете банки в свою папку lib, вы должны вручную добавить их в путь к классам (раздел «Runtime»). Однако определение lib/ в конфигурации build.includes должно помочь в какой-то момент. Также может быть this поможет. Обратите внимание, что вам не нужно «Добавить банку для построения пути», как вы обычно это делали! Добавьте его в раздел Runtime (второй скриншот), добавив его в путь сборки для вас.

Также обратите внимание, что на скриншоте "." не находится в верхней части раздела конфигурации Runtime.

Answer 2

1. log4j доступен как OSGi расслоения: http://ebr.springsource.com/repository/app/bundle/detail;jsessionid=66ADD0FE737BA9A5DD36A052F4A6809A.jvm1?name=com.springsource.org.apache.log4j. В общем случае, если вы хотите использовать стороннюю библиотеку, которая не публикуется в виде пакета OSGi (пока), стоит проверить, имеет ли SpringSource версию OSGi.

2. Если бы это было не так, вы могли бы wrap it as a bundle yourself, как предлагает Александр Гаврилов.

3. Наконец, если вы действительно хотите оставить его в качестве пакета, отличного от OSGi, вам необходимо установить Bundle-ClassPath: ., lib/log4j.jar в MANIFEST.MF.Конечно, это нужно сделать для каждого плагина, который нуждается в банке, и для каждой банки, а также для изменения пути сборки в Eclipse.

Некоторые более уместные вопросы и ссылки: https://stackoverflow.com/questions/5150415/log4j-under-osgi-eclipse-rcp, https://stackoverflow.com/questions/11341627/integrating-3rd-party-jars-into-eclipse-rcp, https://stackoverflow.com/questions/6545212/add-3rd-party-library-to-an-eclipse-plugin.

Мне нужно УПРОЩЕНИЕ, я не хочу обертывать банки в пучки и что-то подобное.

Связки являются банки с немного дополнительной информации в MANIFEST.MF, больше ничего. OSGi (и, следовательно, Eclipse) нуждается в этой информации. Наиболее часто используемые библиотеки уже являются пакетами (просто проверьте для Bundle-SymbolicName в MANIFEST.MF) или доступны в виде пакета. В противном случае обернуть банку нужно только один раз для каждой банки, вместо того, чтобы менять путь сборки, build.properties и Bundle-ClassPath для каждого плагина, который также зависит от банки.