Использование сторонних библиотек в Eclipse RCP Tycho app

Question

Я создал проект котловой плиты после обширного учебника Tycho из Vogella.

Факты:

• Там нет особенности, и нет плагина. Единственным плагином является приложение RCP, которое также является точкой входа.

Проблема:

• Я понятия не имею, в котором pom.xml я включать зависимости 3-й партии.

• Я не может включить их в RCP проекта, так как упаковка этого ПОМ eclipse-plugin, а не jar. Из того, что я заметил, если я поменяю упаковку на jar, тогда автоматически добавится библиотека «Maven Dependencies». Если я вернусь к eclipse-plugin, они будут удалены.

Вопросы:

• Где добавить зависимости? В моем проекте нет pom с упаковкой jar.
• Должен ли я создать отдельный проект с необходимыми JAR? Как включить эту зависимость ко всему моему проекту?
• Действительно ли это хорошая практика создания отдельного плагина и функции для этого приложения RCP?

Похожих решения:

• «Обновить проекты» не работают, и ни сделать п других решений в других SO вопросов.
• Там также this question и that question, но я не в полной мере получить ответы

Answer 1

Я думаю, что у вас есть фундаментальное непонимание.

Maven: Maven определяет все зависимости проекта с помощью pom.xml и автоматически разрешает зависимости переходными (при условии, что все файлы и пом артефактов существуют в хранилищах, вы настроили и правильно объявлять их зависимости).

Tycho: Проблема в том, что Eclipse уже имеет собственную модель проекта на основе файлов продуктов, файлов feature.xml и подключаемых файлов MANIFEST.MF. Tycho использует механизм Maven для Eclipse, но идея состоит в том, что файлы pom.xml просто настраивают подключаемые модули Maven и объявляют тип упаковки. Это обеспечивает точку входа для Maven, но затем Tycho берет верх. Хотя Maven, как правило, строит цепочку зависимостей из информации в pom.xml, Tycho создает изменение зависимости от информации в продукте, функции и файлах MANIFEST.MF. Вы не добавляете никаких зависимостей в файлы pom.xml. Tycho также использует репозитории Eclipse p2 (вместо обычных репозиториев Maven) для поиска зависимых плагинов, которые не найдены в локальных модулях или целевой платформе.

Это на самом деле полезно для многих разработчиков Eclipse, поскольку они уже правильно настроили в своих плагинах, функциях и продуктах Eclipse. Они не хотят повторять все зависимости в pom.xml.

Использование библиотек в Eclipse, плагинов: В Eclipse, если вы хотите использовать библиотеку, которая уже не упакованное как Eclipse, плагин, у вас есть несколько вариантов. Ваш плагин может включать в себя набор JAR в папке libs, а затем включать эту папку libs в plug-in и runtime classpath (см. Файл build.properties). Другой вариант - создать свой собственный «библиотечный плагин», который переупаковывает JAR-библиотеку в качестве подключаемого модуля Eclipse. См. Также https://wiki.eclipse.org/FAQ_What_is_the_classpath_of_a_plug-in%3F. Это ответ, который вы получаете выше.

Проблема заключается в том, что если вы пытаетесь включить сложную библиотеку с несколькими JAR, которые обычно распространяются и включаются в стандартный Java-проект через Maven. Мы столкнулись с этой проблемой с реализацией Джерси JAX-RS в моем проекте. Нет репозитория p2, который включает в себя все части библиотек в виде плагинов с правильной информацией о зависимостях.

простое решение: Если вам нужна общая библиотека, проверить проект Orbit первым, чтобы убедиться в том, что библиотеки уже упакованы как Eclipse, плагинов, http://www.eclipse.org/orbit/. В этом случае вы можете загрузить их и включить их в свою целевую платформу, или вы можете динамически их вытаскивать в (Tycho) времени сборки из своего репозитория p2. Ваши плагины будут включать только эти плагины в качестве зависимостей (в их файлах MANIFEST.MF).

Обходное решение/решение: В нашем случае Джерси JAX-RS не был доступен как плагин Eclipse, и у него была куча транзитивных зависимостей. Обходной путь состоял в том, чтобы создать «библиотечный плагин Eclipse», как я уже упоминал выше, с двумя файлами pom. Сначала мы создали скелетный плагин с пустым папками libs. Один файл pom является стандартным файлом Maven pom с <packaging>jar</packaging>, который объявляет зависимости верхнего уровня, необходимые для реализации Джерси JAX-RS и всех его зависимостей. Зависимости объявляются с помощью <scope>compile</scope>. Мы используем плагин maven-dependency для копирования всех этих зависимостей в папку 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 с этим П вручную время от времени обновлять эти библиотеки, а затем мы просто проверили плагин со всеми его зависимыми банков в системе управления версиями. Проверка сборки позже, я вижу, что мы фактически заполняем папку libs на лету Maven с отдельной задачей сборки непосредственно перед тем, как мы начнем часть Maven/Tycho сборки. Разумеется, входящие в комплект поставки файлы «Bundle-ClassPath» и «Экспорт-пакет» файла модуля «МАНИФЕСТ-МФ» поступают прямо из источника. Мы должны время от времени проверять их, чтобы они соответствовали библиотекам и пакетам, которые мы получаем от Maven. (Это не имеет тенденций к существенному изменению, если мы не ударим основные версии библиотеки или не добавим новую зависимость на уровне Maven.) В build.properties плагина есть папка libs/как часть bin.includes.

В среде разработки, после первого ознакомления с кодом, мы просто запускаем mvn (с конфигурацией запуска внешних инструментов, которая также проверяется вместе с проектом) в файле pom-файлов проекта «copy dependencies». Это заполняет папку libs всеми библиотеками JAX-RS и зависимостями.Нам просто нужно запустить его снова, когда мы обновляем что-то о зависимостях или когда мы прыгаем между ветвями, которые имеют разные версии зависимостей JAX-RS. Мы устанавливаем .gitignore, чтобы гарантировать, что мы не передадим libs Git.

Другой pom для этого проекта настроен как обычный файл pom Tycho с <packaging>eclipse-plugin</packaging>. Во время нашей автоматической сборки мы запускаем один шаг на ранней стадии процесса сборки (сразу после проверки), который вызывает mvn с jar pom для заполнения libs. Затем мы переходим к основной сборке Maven/Tycho с использованием pom-eclipse-plugin. Плагин-плагин eclipse-plugin не имеет информации о зависимости (как я уже говорил выше). Это просто дает Tycho способ распознать подключаемый модуль Eclipse и построить его на основе его файлов MANIFEST.MF и build.properties. Но встроенный подключаемый модуль включает и предоставляет все те библиотеки, которые были заполнены вызовом mvn на шаг jar pom.

Итак, это немного беспорядок, но это лучшее решение, которое мы нашли пару лет назад, когда мы столкнулись с этой проблемой. Я не уверен, делает ли Tycho какую-либо работу, чтобы разрешить какую-то гибридную сборку Maven/Tycho, которая могла бы сделать это автоматически как часть сборки. Наверное, я должен спросить разработчиков. :)

Ваши вопросы:

• Где добавить зависимости? В моем проекте нет помпы с упаковкой банками. Ответ: Обходной путь выше позволяет вам сделать это с одним проектом. У вас только два файла pom, например pom_deps.xml и pom.xml. Вам просто нужно вызвать pom_deps.xml отдельно, чтобы заполнить папку libs (в среде dev и с вашими автоматическими сборками).
• Должен ли я создать отдельный проект с необходимыми JAR? Как включить эту зависимость ко всему моему проекту? Ответ: обходной путь, описанный выше, позволяет сделать это с помощью одного проекта. Другой способ сделать это - создать отдельный JAR-проект, но я не думаю, что ваше приложение Eclipse RCP действительно может включить модуль <packaging>jar</packaging> в полезный способ. Единственный способ, которым я нашел это, - использовать аналогичное обходное решение. Сначала вы создаете модуль JAR, устанавливаете его в репозиторий maven, а затем один из ваших проектов подключаемых модулей объединяет JAR в свою папку libs. (Если вы действительно хотите это сделать, спросите. У нас есть случай, когда мы тоже должны это сделать, и я могу предоставить шаги, которые мы делаем в процессе разработки и сборки, чтобы заставить его работать. Я думаю, что обходной проект что я предоставил выше, имеет больше смысла для вашего дела.)
• Действительно ли это хорошая практика создания отдельного плагина и функции для этого приложения RCP? Ответ: это действительно отдельный вопрос. Если у вас есть функция с несколькими плагинами, у вас такая же проблема. Tycho может обрабатывать продукт/функцию/плагины, но не может переходить на разрешение зависимостей на основе Maven. Вы в конечном итоге, использовать те же методы обход

Резюме: Основная проблема в том, что Eclipse, подключаемые модули не могут «видеть» голую библиотеку JAR. Плагин должен иметь библиотеку, включенную в ее локальную папку libs (с соответствующей записью Bundle-ClassPath в MANIFEST.MF), или она должна зависеть от некоторого другого подключаемого модуля, который экспортирует соответствующие пакеты. Tycho просто разрешает зависимости через плагины Eclipse и не может использовать нормальное разрешение зависимости Maven напрямую, чтобы вытащить кучу JAR. Если все ваши зависимости уже подключаемые модули, вы в порядке. Если нет, возможно, вам придется использовать обходной путь выше, чтобы упаковать набор библиотек для использования ваших плагинов.