Создание репозитория p2 путем разрешения функций Tycho из репозитория Maven

Я пытаюсь создать репозиторий p2 из артефактов объектов Tycho, которые развернуты в удаленном репозитории Maven, без необходимости сначала устанавливать артефакты в локальный репозиторий Maven (как в Tycho не может разрешить ссылку с продукта на функцию затмения из другой сборки реактора) и без необходимости объединять все функции и хранилище в едином корпусе реактора.

Фон

У меня есть многомодульный проект Tycho, который создает несколько плагинов и функций Eclipse.

Для того, чтобы я мог строить каждый модуль отдельно - и поэтому я могу ссылаться на артефакты OSGI в нашем репозитории Nexus Maven - я включил <pomDependencies>consider</pomDependencies> на моей целевой платформе и добавил зависимости Maven между модулями или артефактами репозитория как обычно с элементами <dependency/>.

Это хорошо работает - я могу создавать функции или запускать тесты плагинов без их зависимых плагинов, которые находятся либо в моем локальном хранилище Maven, либо в том же реакторе. Например, когда я запускаю mvn test в проекте тестирования плагина, соответствующие зависимости будут загружены из Nexus, и Tycho с радостью разрешит Import-Package в моем манифесте против них, построит все и запустит тесты. Пока все хорошо.

Я хотел бы сгенерировать репозиторий p2 из этих функций, чтобы я мог их установить в Eclipse с сайта обновлений, а рекламируемый способ сделать это - с типом упаковки eclipse-repository. Но здесь план падает - Tycho, похоже, не в состоянии разрешить зависимостей функций при создании репозиториев так же, как он может разрешать зависимостей плагинов при построении функций. Все попытки дают:

[ERROR] Cannot resolve project dependencies:
[ERROR]   Software being installed: my.eclipse.repository raw:0.0.1.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):0.0.1-SNAPSHOT
[ERROR]   Missing requirement: my.eclipse.repository raw:0.0.1.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):0.0.1-SNAPSHOT requires 'my.prj.eclipse.project.feature.feature.group 0.0.0' but it could not be found

Есть два способа, с помощью которых я успешно создал репозиторий p2:

  • Как часть той же реакторной сборки. Если я создам модуль eclipse-repository в рамках многомодульного проекта Tycho и сразу создам весь проект с помощью, например, mvn verify, функции решены отлично. Но я не хочу этого делать. Я бы предпочел строить модули по отдельности. Это означает, что наш CI может иметь индикатор для каждого модуля, и мы можем сразу увидеть, какие тесты модуля не удались; это дает нам возможности для параллельных сборок; и мы не должны постоянно работать над модулями, которые не изменились. Было бы позором использовать монолитную сборку Maven.
  • Если я устанавливаю проект Tycho в свой локальный репозиторий Maven, запустив mvn install в зависимости. Но я тоже не хочу этого делать, потому что это будет означать, что сборка по своей сути невоспроизводима, поскольку она будет чувствительна к состоянию локального репозитория. Наш CI в настоящее время настроен на поддержание репозитория Maven на каждое задание и полностью уничтожить его в начале исполнения, чтобы защитить нас от этой потенциальной беспорядочности.

Итак, мой вопрос: есть ли третий способ? Есть ли способ заставить плагин Tycho отвечать за создание типов упаковки eclipse-repository для загрузки функций из удаленного хранилища Maven? Или любым другим способом я могу построить репозиторий p2 из плагинов, которые были индивидуально построены и развернуты в репозитории Maven?

Вещи, которые я пробовал, включают:

  • определение зависимостей функции Maven как jar, так и eclipse-feature
  • явно добавление функций на целевую платформу, например

    ... <artifactId>target-platform-configuration</artifactId> <version>${tycho.version}</version> <configuration> <dependency-resolution> <extraRequirements> <requirement> <type>eclipse-feature</type> <id>my.prj.eclipse.project.feature</id> <versionRange>0.0.0</versionRange> </requirement> ...


ближайшая вещь, которую я нашел достойному решению, имеет многомодульный проект Tycho, который содержит только репозиторий и функции.

feature-project
 |- feature1    (eclipse-feature)
 |- feature2    (eclipse-feature)
 |- repository  (eclipse-repository)

Построение этого работает - все плагины, добавленные в POM верхнего уровня, загружаются из Nexus, доступны для включения в каждую функцию и включены в сгенерированный репозиторий.

Однако это далеко не идеально, потому что я больше не могу хранить свои функции логически рядом с моими плагинами; они должны быть в отдельных иерархиях проектов. Попытка построить функции и репозиторий отдельно, например, с помощью mvn clean verify -pl :feature1,feature2,repository, предположительно происходит из-за Ошибка 380152.

Есть ли лучший способ? Любая помощь будет с благодарностью принята.

Большое спасибо


(В стороне: создание репозитория с mvn clean verify -Dtycho.localArtifacts=ignore будет успешным, если функции присутствуют в локальном репозитории Maven и не покажет вам предупреждение о том, что артефакты устраняются из local repo... это ошибка?)

Ответ 1

Я очень впечатлен вашим тщательным анализом. Вы почти все покрыли, что возможно с текущей версией Tycho (0.22.0) - за исключением решения, которое так неинтуитивно, что я не ожидал, что кто-нибудь сможет его угадать (см. Ниже). Обратите внимание, однако, что существует небольшое исправление, необходимое для решения проблемы для артефактов SNAPSHOT.

Но сначала я хотел бы предоставить некоторый технический (и исторический) фон для того, что вы наблюдали:

pomDependencies = рассматривает только работы для плагинов: прецедентом для этой функции было разрешить ссылку плагинов (или, точнее, пакетов OSGi) из хранилищ Maven. Поэтому, когда флаг установлен, и проект имеет зависимости от JAR, Tycho проверяет, являются ли они пакетами OSGi, генерирует метаданные p2 для них на лету и добавляет их на целевую платформу. Подобной поддержки JAR-функций нет, поскольку они обычно не существуют в репозиториях Maven.

Но как насчет Tycho-построенных проектов? Они могут развертываться в хранилищах Maven! Да, это правда, и именно поэтому я попытался расширить концепцию pomDependencies, чтобы обеспечить то, что вы пытаетесь сделать. Идея заключалась в том, что каждый раз, когда Tycho рассматривает зависимость POM для целевой платформы, он также проверяет, существуют ли файлы индекса p2 ...-p2metadata.xml и ...-p2artifacts.xml. Однако это оказалось причиной серьезного снижения производительности, поскольку для сервера хранилища Maven обычно очень сложно понять, что артефакт не существует. Поэтому удаленная загрузка была отключена и заменена поиском в локальном репозитории Maven. Таким образом, две сборки Tycho могут установить -Dtycho.localArtifacts=ignore и по-прежнему смогут обменивать артефакты, указанные в POM, через локальный репозиторий Maven.

Зная эти детали реализации, мы переходим к следующему решению: вместо того, чтобы добавлять только значение POM из репозитория в артефакт объекта, вам также нужно добавить зависимости к файлам p2metadata и p2artifacts. Пример:

<dependencies>
    <dependency>
        <groupId>myproject</groupId>
        <artifactId>myproject.feature</artifactId>
        <version>0.1.0-SNAPSHOT</version>
    </dependency>
    <dependency>
        <groupId>myproject</groupId>
        <artifactId>myproject.feature</artifactId>
        <version>0.1.0-SNAPSHOT</version>
        <classifier>p2metadata</classifier>
        <type>xml</type>
    </dependency>
    <dependency>
        <groupId>myproject</groupId>
        <artifactId>myproject.feature</artifactId>
        <version>0.1.0-SNAPSHOT</version>
        <classifier>p2artifacts</classifier>
        <type>xml</type>
    </dependency>
</dependencies>

Это заставляет Maven также загружать эти файлы индекса p2, поэтому Tycho распознает главный артефакт как артефакт Tycho. Таким образом, вы также можете получить функцию eclipse в целевой платформе через зависимости POM - по крайней мере, почти: с 0.22.0, сборка репозитория проходит, но артефакт feature.jar отсутствует. Я уже отладил эту проблему, и легко исправить.

Очевидно, что синтаксис с тремя элементами <dependency> для каждой фактической зависимости не является приятным. Должно быть возможно сварить это до одного элемента p2artifacts, но это больше работает. Если вы заинтересованы в этой функции, вы можете открыть запрос расширения в Tycho issue tracker.