Обработка зависимостей без OSGi при интеграции Maven, Tycho и Eclipse

У меня есть куча плагинов на основе Eclipse, которые я переношу в Maven/Tycho. Большинство из этих плагинов зависят от отдельных библиотек, которыми я теперь управляюсь через Maven, а не путаются с файлами .jar.

Самая громоздкая часть моей текущей установки связана с очевидной неспособностью Tycho обрабатывать артефакты Maven-only (то есть не OSGi). Моя текущая настройка работает следующим образом:

  • В pom.xml каждого плагина Eclipse я выдаю unpack цель maven-dependency-plugin во время фазы initialize. Это распаковывает артефакты, которые я указываю в отдельный каталог target/dependencies.

  • Каталог target/dependencies добавляется как выходной каталог в build.properties, так что Tycho может добавить его в путь к классам при компиляции:

    source.. = src/main/java/
output.. = target/classes/
output.. = target/dependencies/

  • Каталог target/dependencies добавляется в библиотеку Bundle-ClassPath в META-INF/MANIFEST.MF.

Эти параметры позволяют директиве compile Maven компилировать плагин. Импорт проекта из VCS и вручную указание каталога target/dependencies в виде папки класса в Eclipse позволяет указанной среде IDE также скомпилировать плагин.

К сожалению, это довольно громоздкое решение по нескольким причинам:

  • Для настройки maven-dependency-plugin необходимо указать все артефакты, которые необходимо распаковать. Можно использовать unpack-dependencies вместо unpack, но это также будет распаковывать все зависимости OSGi - наличие половины Eclipse, распакованного в каждом каталоге проекта, не является моей идеей веселья...

  • Добавление папки класса в Eclipse требует, чтобы Maven initialize запускался один раз, поэтому создается каталог target/dependencies.

  • Между чистыми проектами Maven и их зависимыми проектами Tycho в Eclipse нет никакого источника. Для изменения распространения с проекта Maven на проект Tycho, чтобы, например, Eclipse может показать потенциальную проблему компиляции, нужно выполнить mvn install проект Maven, а затем запустить mvn clean initialize в проекте Tycho, чтобы удалить ранее распакованные зависимости и потянуть текущий набор. Затем вам нужно обновить проект Eclipse и надеяться, что Eclipse пойдет правильно.

    В том же духе просмотр источника зависимости из проекта Tycho не отображает первичный исходный файл, а скорее все, что доступно в target/dependencies - вполне возможно, только файл .class.

Я думаю, что должен быть более разумный способ сделать это - что-то, что позволит проектам Eclipse и Maven более тесно интегрироваться.

Итак, что мне не хватает? Какова рекомендуемая настройка для этого варианта использования? Есть ли лучшая альтернатива? Предпочтительно что-то, что не требует установки связки репозиториев Nexus и/или p2?

Ответы

Ответ 1

Похоже, мы применяем аналогичные стратегии. Тем не менее, я использую смешанный репозиторий связи (имеющий как maven, так и p2).

  • Для распаковки зависимостей я использую плагин maven-dependency, чтобы поместить их в цель/зависимость (см. ниже).
    • 1.1. копии-зависимости делают без необходимости распаковки.
  • Ваш источник и вывод примерно такие же, как у меня.
    • 2,1. Да, mvn должен инициализировать целевые/зависимости
  • Я включаю только необходимые банки в MANIFEST, потому что 1 будет извлекать много ненужных банок.
    • 3.1. Я вручную выбираю соответствующие банки.
    • 3,2. Да, если не-Eclipse, управляемый (специалист) проекты изменений (за пределами вашего рабочего пространства), то вы должны запустить MVN построить, чтобы обновить их.
    • 3.3. Ключом к выполнению этой работы является:
      • 3.3.1 Разверните проекты maven и Eclipse в репозиторий (моментальный снимок). Я использую http://www.sonatype.org/nexus/. Таким образом, при запуске maven он ищет репозиторий nexus для обновлений проектов maven и Eclipse.
  • Некоторые другие заметки, которые могут быть очевидны:
    • 4,1. Файл pom.xml должен содержать только не-Eclipse jars в качестве зависимостей. (The Tycho плагин обрабатывает все зависимости Eclipse, которые должны быть найдены в вашем (связующей) хранилище.)
    • 4,2. Добавьте зависимые банки в среду выполнения в Eclipse (путем редактирования среды выполнения plugin.xml).

Плагин Maven:

        <plugin>
            <!-- Copy non-Ecipse plugins to target/dependency so that may be referenced 
                for runtime use. -->
            <artifactId>maven-dependency-plugin</artifactId>
            <version>2.1</version>
            <executions>
                <execution>
                    <id>copy-dependencies</id>
                    <goals>
                        <goal>copy-dependencies</goal>
                    </goals>
                    <configuration>
                        <excludeGroupIds>org.XXX</excludeGroupIds>
                    </configuration>
                </execution>
                <execution>
                    <id>classpath</id>
                    <goals>
                        <goal>build-classpath</goal>
                    </goals>
                    <configuration>
                        <fileSeparator>/</fileSeparator>
                        <prefix>target/dependency</prefix>
                        <outputFile>${project.build.directory}/classPath.txt
                        </outputFile>
                    </configuration>
                </execution>
            </executions>
        </plugin>

Пример build.properties

bin.includes = META-INF/,
target/classes/,
plugin.xml,
target/dependency/mongo-java-driver-2.11.3.jar

Пример манифеста (только подмножество банок):

Bundle-ClassPath: .,
target/classes/,
target/dependency/mongo-java-driver-2.11.3.jar

Ответ 2

Вы можете попробовать maven-bundle-plugin с Embed-Dependency.

См. http://wiki.eclipse.org/Tycho/How_Tos/Dependency_on_pom-first_artifacts

Официальная демонстрация работает хорошо. Тем не менее, мне все еще не удается использовать файл jar таким образом.

Ответ 3

Официальная демонстрация действительно работает хорошо и показывает способ встраивания зависимостей, отличных от OSGI, или, другими словами, создавать OSGI-фасад для других зависимостей.

Способ действительно копирует зависимости вручную, делая их частью манифеста OSGI и экспортируя интересующие пакеты.

Реальная проблема - это, однако, выполнение плагина зависимости из Eclipse.

Просто не запускается, даже с соответствующим соединителем M2E, тем самым блокируя обнаружение и разрешение класса класса PDE.