Использование сторонних библиотек в приложении Eclipse RCP Tycho
Я создал проект котельной плиты после обширного учебника Tycho vogella.
факты:
- нет никакой функции, и нет плагина. Единственным плагином является приложение RCP, которое также является точкой входа.
:
Я понятия не имею, в каком
pom.xml
Я включаю зависимости третьей стороны.Я не может включите их в проект RCP, потому что упаковка этого pom
eclipse-plugin
, а неjar
. Из того, что я заметил, Если я изменю упаковку наjar
, затем автоматически добавляется библиотека "зависимости Maven". Если я вернусь кeclipse-plugin
, они удаляются.
вопросы:
- где добавить зависимости? Там нет pom с
jar
упаковка в моем проекте. - должен ли я создать отдельный проект с необходимыми банками? Как включить эту зависимость во весь проект?
- действительно ли это хорошая практика для создания отдельного плагина и функции для этого приложения RCP?
соответствующие решения:
- "проекты обновления" не работают, и ни одно другое решение в других вопросах SO не работает.
- там же этот вопрос и этот вопрос, но я не полностью получить ответы
2 ответов
Я думаю, что у вас фундаментальное непонимание.
Maven: Maven определяет все зависимости проекта через pom.xml и автоматически разрешает транзитивные зависимости (при условии, что все файлы и артефакты pom существуют в репозиториях, которые вы настроили и правильно объявили их зависимости).
тихо: проблема в том, что Eclipse уже имеет свою собственную модель проекта, основанную на файлах продукта, функции.XML файлы и манифест подключаемого модуля.MF файлов. Тихо использует механизм Maven для Eclipse, но идея заключается в том, что pom.xml-файлы просто настраивают подключаемые модули Maven и объявляют тип упаковки. Это обеспечивает точку входа для Maven, но затем Tycho берет на себя. В то время как Maven обычно строит цепочку зависимостей из информации в pom.xml-файлы, Tycho строит изменение зависимости от информации в продукте, функции и манифеста.MF файлов. Вы не помещаете никаких зависимостей в ПФЛ.XML-файл. Tycho также использует репозитории Eclipse p2 (вместо обычных репозиториев Maven) для поиска зависимых плагинов, которые не найдены в локальных модулях или целевой платформе.
это на самом деле преимущество для многих разработчиков Eclipse, поскольку они уже настроили все правильно в своих плагинах Eclipse, функциях и продуктах. Они не хотят повторять все зависимости в pom.XML.
использование библиотек в Eclipse Плагины: в Eclipse, если вы хотите использовать библиотеку, которая еще не упакована как плагин Eclipse, у вас есть несколько вариантов. Подключаемый модуль может включать набор JARs в папку libs, а затем включать эту папку libs в путь к классам подключаемого модуля и среды выполнения (см. сборку.файл свойств.) Другой вариант-создать свой собственный "библиотечный плагин", который переупаковывает библиотеку JAR как плагин Eclipse. Смотреть также https://wiki.eclipse.org/FAQ_What_is_the_classpath_of_a_plug-in%3F. Это ответ, который вы получаете выше.
проблема в том, что если вы пытаетесь включить сложную библиотеку с несколькими банками, которая обычно распределена и включена в стандартный проект Java через Maven. Мы столкнулись с этой проблемой с реализацией JAX-RS в моем проекте. Нет репозитория p2, который включает все части библиотек в качестве плагинов с правильным информация о зависимостях.
Простое Решение: Если вам нужна общая библиотека, сначала проверьте проект Orbit, чтобы увидеть, были ли библиотеки уже упакованы как плагины Eclipse,http://www.eclipse.org/orbit/. В этом случае вы можете загрузить их и включить в свою целевую платформу, или вы можете динамически вытаскивать их во время сборки (Tycho) из своего репозитория p2. Ваши плагины будут просто включать эти плагины в качестве зависимостей (в их манифест.MF files).
Обходной Путь / Решение: в нашем случае Jersey JAX-RS не был доступен в качестве плагина Eclipse, и у него была куча транзитивных зависимостей. Обходной путь состоял в том, чтобы создать плагин библиотеки Eclipse, как я упоминал выше, с двумя файлами pom. Первоначально мы создали плагин skeleton с пустой папки libs. Один файл pom - это просто стандартный файл Maven pom с <packaging>jar</packaging>
, который объявляет верхнего уровня зависимости вытащить реализацию JAX-RS Джерси и все ее зависимости. Зависимости объявляются с помощью <scope>compile</scope>
. Мы используем Maven-dependency-plugin для копирования всех этих зависимостей в папку libs проекта.
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>compile</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>libs</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
мы фактически закончили запуск Maven с этим pom вручную время от времени, чтобы обновить библиотеки, а затем мы просто проверили плагин со всеми его зависимыми банками в систему управления версиями. проверка сборки позже, я вижу, что мы фактически заполните папку libs на лету с Maven отдельной задачей сборки непосредственно перед запуском части сборки Maven/Tycho. Конечно, записи Bundle-ClassPath и Export-Package файла MANIFEST-MF плагина поступают прямо из системы управления версиями. Мы должны проверять их время от времени, чтобы убедиться, что они соответствуют библиотекам и пакетам, которые мы получаем от Maven. (Это не имеет тенденцию сильно меняться, если мы не сталкиваемся с основными версиями библиотеки или не добавляем новую зависимость в Уровень Maven.) Сборка плагина.свойства имеет libs / папку как часть bin.включает.
в среде разработки после первой проверки кода мы просто запускаем mvn (с конфигурацией запуска внешних инструментов, которая также зарегистрирована в проекте) в файле pom проекта "копировать зависимости". Это заполняет папку libs всеми библиотеками и зависимостями JAX-RS. Нам нужно только запустить его снова, когда мы обновляем что-то о зависимостях или когда мы переход между ветвями, имеющими разные версии зависимостей JAX-RS. Мы сели .gitignore, чтобы гарантировать, что мы не передадим libs Git.
другой pom для этого проекта настроен как обычный файл Tycho pom с <packaging>eclipse-plugin</packaging>
. Во время нашей автоматической сборки мы запускаем один шаг в начале процесса сборки (сразу после проверки), который вызывает mvn с помощью jar pom для заполнения библиотек. Затем мы приступаем к основной сборке Maven/Tycho, используя Eclipse-plugin pom. В Eclipse-плагина pom не имеет информации о зависимостях (как я сказал выше). Это просто предоставляет Tycho способ распознать плагин Eclipse и построить его на основе его манифеста.MF и строить.файл свойств. Но встроенный плагин включает и предоставляет все те библиотеки, которые были заполнены вызовом mvn на шаг jar pom.
Итак, это немного беспорядок, но это лучшее решение, которое мы нашли пару лет назад, когда мы столкнулись с этой проблемой. Я не уверен, делает ли тихо какую-либо работу, чтобы разрешить некоторые своего рода гибридная сборка Maven/Tycho, которая может сделать это автоматически как часть сборки. Наверное, надо спросить у разработчиков. :)
вопросы:
- где добавить зависимости? В моем проекте нет pom с упаковкой банок. ответ: обходной путь выше позволяет сделать это с одним проектом. Вы просто два пом файлов, как pom_deps.xml и pom.XML. Вам просто нужно вызвать pom_deps.xml отдельно для заполнения папки libs (в среде разработки и с автоматической сборкой).
-
должен ли я создать отдельный проект с необходимыми банками? Как включить эту зависимость во весь проект? ответ: обходной путь, который я описал выше, позволяет сделать это с одного проекта. Другой способ сделать это-создать отдельный проект JAR, но я не думаю, что ваше приложение Eclipse RCP действительно может включать
<packaging>jar</packaging>
модуль полезным способом. Единственный способ, который я нашел. он должен использовать аналогичный обходной путь. Сначала вы создаете модуль JAR, устанавливаете его в репозиторий maven, а затем один из ваших подключаемых проектов связывает JAR в папку libs. (Если вы действительно хотите сделать это таким образом, спросите. У нас есть случай, когда мы должны сделать это тоже, и я могу предоставить шаги, которые мы делаем в разработке и сборке, чтобы заставить его работать. Я думаю, что один обходной путь проекта, который я предоставил выше, имеет больше смысла для вашего случая.) - это действительно так большая часть хорошей практики для создания отдельного плагина и функции для этого приложения RCP? ответ: это действительно отдельный вопрос. Если у вас есть функция с несколькими плагинами, у вас та же проблема. Tycho может обрабатывать продукт / функцию / плагины, но он не может перейти в разрешение зависимостей на основе Maven. Вы в конечном итоге придется использовать те же обходные пути
резюме: основная проблема заключается в том, что плагины Eclipse не могут "видеть" голую банку библиотека. Подключаемый модуль должен иметь библиотеку, включенную в локальную папку libs (с соответствующей записью Bundle-ClassPath в MANIFEST.MF), или он должен зависеть от какого-либо другого плагина, который экспортирует соответствующие пакеты. Tycho просто разрешает зависимости через плагины Eclipse, и он не может напрямую использовать нормальное разрешение зависимостей Maven, чтобы вытащить кучу банок. Если все ваши зависимости уже являются плагинами, все в порядке. Если нет, вам может потребоваться использовать обходной путь выше для упаковки набор библиотек для использования плагинами.
просто добавив плагин к зависимостям pom и включая запись <pomDependencies>consider</pomDependencies>
в комплектации target-platform-configuration
заставляет его работать.
<plugins>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>${tycho.version}</version>
<configuration>
<!-- The configuration to make tycho consider the maven dependencies -->
<pomDependencies>consider</pomDependencies>
<!-- other configurations -->
</configuartion>
</plugin>
<!-- other plugins-->
</plugins>
<dependencies>
<!-- An example third-party bundle (plugin) present in maven repository-->
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.gogo.shell</artifactId>
<version>1.1.0</version>
</dependency>
</dependencies>
ссылка здесь.