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

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

введите описание изображения здесь

Факты:

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

Проблема:

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

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

Вопросы:

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

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

  • "Обновить проекты" не работает, и ни одно другое решение в других вопросах SO не работает.
  • Там также этот вопрос и этот вопрос, но я не полностью получаю ответы

Ответ 1

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

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

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 с этим pom вручную время от времени, чтобы обновить libs, а затем мы просто проверили подключаемый модуль со всеми его зависимыми JAR в исходное управление. Проверка позже я вижу, что мы фактически заполняем папку libs на лету Maven с отдельной задачей сборки непосредственно перед тем, как мы начнем часть Maven/Tycho сборки. Разумеется, плагины файлов MANIFEST-MF Bundle-ClassPath и Export-Package поступают прямо из исходного управления. Мы должны время от времени проверять их, чтобы они соответствовали библиотекам и пакетам, которые мы получаем от Maven. (Это не имеет тенденций сильно меняться, если мы не ударим основные версии библиотеки или не добавим новую зависимость на уровне Maven.) Плагин build.properties имеет папку libs/как часть bin.includes.

В среде разработки, после того, как мы сначала проверим код, мы просто запустим mvn (с конфигурацией запуска внешних инструментов, которая также была включена в проекте) в файле pom "копирование зависимостей". Это заполняет папку 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. Если все ваши зависимости уже подключаемые модули, вы в порядке. Если нет, возможно, вам придется использовать обходной путь выше, чтобы упаковать набор библиотек для использования ваших плагинов.