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

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

enter image description here

факты:

  • нет никакой функции, и нет плагина. Единственным плагином является приложение 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>

ссылка здесь.