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

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

фон

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

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

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

я хотел бы создать репозиторий 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 Multi-module, и постройте весь проект сразу с помощью, например,mvn verify функции решаются нормально. Но я не хочу этого делать. Я бы предпочел строить модули индивидуально. Это означает, что наш CI может иметь индикатор для каждого модуля, и мы можем сразу увидеть, какие тесты модуля потерпели неудачу; это дает нам возможности для распараллеливания сборок; и мы избегаем необходимости постоянно запускать сборки на модулях, которые не изменились. Было бы стыдно использовать монолитный Maven строить.
  • если я установлю проект Tycho в свой локальный репозиторий Maven, работает mvn install на эту зависимость. Но я тоже не хочу этого делать, потому что это будет означать, что сборка по своей сути непродуктивна, так как она будет чувствительна к состоянию локального репозитория. Наш CI в настоящее время настроен на поддержание репозитория Maven для каждого задания и полностью стереть его в начале выполнения, чтобы защитить нас от этого потенциала беспорядок.

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

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

  • указание depedencies функции 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 и не показывают предупреждение о том, что артефакты разрешаются из локального репозитория... это ошибка?)

10
eclipse-plugin maven tycho

1 ответов

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

но сначала я хотел бы предоставить некоторые технические (и исторические) предпосылки для того, что у вас есть заметил:

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

но как насчет тихо-построенных проектов? Они могут развертываться в репозитории Maven! Да, это правда, и именно поэтому я попытался расширить концепцию pomDependencies, чтобы учесть то, что вы пытаетесь сделать. Идея заключалась в том, что каждый раз, когда Tycho рассматривает зависимость POM для целевой платформы, он также проверяет, являются ли файлы индекса p2 ...-p2metadata.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 сборка репозитория проходит, но функция.артефакт jar отсутствует. Я уже отладил эту проблему, и это легко исправить.

очевидно, синтаксис с тремя <dependency> элементы для каждой фактической зависимости нехорошо. Это должно быть возможно свести к одному p2artifacts элемент - но это больше работы. В случае, если вы заинтересованы в этой функции, вы могли бы открыть тикет в баг-трекере тихо.

7