Как правильно настроить многомодульный проект Maven со скользящими циклами выпуска
Я пытаюсь разработать лучший способ настройки нашего многомодульного проекта Apache Maven таким образом, чтобы обеспечить разрозненные циклы выпуска модулей и не вводить проблемы зависимости при отладке проекта.
в настоящее время у нас есть установка по образцу:
- bigsystem@1.2
- Родительский-1.1-снимок
- модуль a@1.4-SNAPSHOT
- родители parent@1.1-SNAPSHOT
- модуль b@1.3-SNAPSHOT
- родители parent@1.1-SNAPSHOT
- зависит от a@1.1
- модуль c@1.1-SNAPSHOT
- родители parent@1.1-SNAPSHOT
- зависит от a@1.2
- зависит от b@1.1
зависимости, объявленные в модулях b и c, содержат минимальную версию, необходимую для компиляции модуля, которая не обязательно является текущей версией модуля, или версия развертываемого модуля.
с точки зрения сборки это хорошо работает, каждый модуль может быть выпущен / обновлен по мере необходимости, однако при попытке отладки развернутого приложения под IntelliJ IDEA (версии 8 и 9 EAPs) открыв POM верхнего уровня, IDEA решает, что, поскольку мы объявили зависимость от a@1.2, что каждый раз, когда мы входим в один из классов a, он должен открывать его из источников a-1.2.jar, а не ток a@1.4 источники в проекте. Это еще смущенный тем фактом, что шаг в любой из классов b приводит нас к b@1.1 вместо b@1.3 - ...
моей первоначальной попыткой обойти это было объявить номера версий в разделе dependencyManagement родительского pom и просто наследовать версию субмодулями. Это сработало до степени решения проблемы отладки идеи, поскольку раздел dependencyManagement может указать всем на текущие версии моментальных снимков.
Это, к сожалению, вызывает проблемы, когда выполнение выпуска maven из-за необходимости освободить Родительский pom перед выпуском модуля, но поскольку родитель может ссылаться на несколько моментальных снимков в разработке, он не может быть выпущен, и мы в конечном итоге добавляем ссылки на версии обратно в модули pom для удовлетворения выпуска.
казалось бы, Использование раздела dependencyManagement maven будет действительно хорошо работать, только если мы выпускаем все пакеты одновременно, независимо от того, изменились ли они, но поскольку мы хотим управлять выпусками каждый субмодуль только при необходимости эта модель не подходит.
У меня есть подозрение, что я что-то упускаю, и что комбинация dependencyManagement и диапазонов версий может удовлетворить требования, хотя я еще не видел, чтобы диапазоны версий работали должным образом.
есть ли лучший способ? Правильный путь?
4 ответов
Я бы рекомендовал не делать их модулями, а сделать их независимыми POMs. Таким образом, вам не нужно беспокоиться о попытке удовлетворить родительские зависимости POM. Поскольку они выпускаются независимо, они действительно должны иметь независимые объектные модели проекта. Подумайте об Apache Commons как о шаблоне.
Я думаю, что проблема с IDEA возникает потому, что вы используете корневой POM в своей исходной структуре для выполнения двух вещей, которые обычно взаимоисключающие в Maven. Сначала вы используете POM в качестве местоположения для хранения общих сведений о конфигурации для несвязанных (с точки зрения сборки) проектов Maven. Во-вторых, вы используете POM в качестве агрегатора для своей сборки. Вы можете делать все это, не делая друг друга.
Как сказал Роб, удалите модуль a,b и т. д. проекты из раздела "модули" вашего родительского POM. Во-вторых, переместите Родительский POM в свой собственный каталог, поскольку он действительно является братом других модулей в отношении процесса сборки и выпуска. То, как у вас это сейчас, это больше родитель/агрегатор.
то, как у вас есть сейчас, также не поддается тегированию и выпуску каждого модуля отдельно в качестве тега вашего родительского POM, вероятно, без необходимости будет включать все подпапки модуля.
файл структура будет выглядеть так:
- родитель
- пом.в XML
- модуль a
- пом.в XML
- модуль X
- пом.в XML
Что касается того, что вам не хватает, dependencyManagement не очень хорошо подходит для управления версиями для зависимостей внутри проекта. Это зависимости между модулями внутри агрегированной сборки. Это больше подходит для объявления глобальных версий для внешних зависимостей.
окончательное / рабочее решение, которое мы использовали, было довольно похоже на то, с чего мы начали. Фактическая структура проекта остается прежней:
- bigsystem@1.2
- Родительский-1.1-снимок
- модуль a@1.4-SNAPSHOT o родители parent@1.1-SNAPSHOT
- модуль b@1.3-SNAPSHOT o родители parent@1.1-SNAPSHOT o зависит от a@1.1
- модуль c@1.1-SNAPSHOT o родители parent@1.1-SNAPSHOT o зависит от a@1.2 о зависит от b@1.1
- распределение a@1.2-SNAPSHOP
однако основные различия заключаются в том, что:
- Родительский модуль не включает никаких версий артефакты проекта
- отдельные модули полностью объявляют свои зависимости от проекта и указывают диапазон версий, т. е. [1.0.0, 1.1.0)
- все модули начинают там циклы номера версии от .1, i.E 1.0.1-SNAPSHOT, это позволяет версии диапазон, удовлетворяемый начальными снимками (1.0.0-снимок раньше, чем 1.0.0 final, поэтому не включен).
- распределение pom (первоначально не показано в вопросе) идентифицирует точно версия, которая будет развернута / включена в определенный выпуск.
- удалите все моментальные снимки проекта из локального репозитория maven при выпуске, чтобы выпускать только диапазоны (или использовать-Dmaven.РЕПО.local= / tmp / sometemprepo для свежего локального РЕПО)
Это делает каждый модуль более автономный и дает нам свободу выпускать и развертывать новые версии наших артефактов проекта с минимальной суетой.
Они, безусловно, кажутся отдельными модулями. Какие преимущества вы получаете, разбивая их вместе, если они имеют разные зависимости, даже в рамках многомодульного проекта?