Как правильно настроить многомодульный проект Maven с циклами скользящего выпуска

Question

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

В настоящее время у нас есть установка в соответствии с:

• bigsystem@1.2
  • родитель-1,1-СНАПШОТ
  • модуль a@1.4-SNAPSHOT
    • родительский родитель@1.1-SNAPSHOT
  • модуль b@1.3-SNAPSHOT
    • родительский родитель@1.1-SNAPSHOT
    • зависит от a@1.1
  • модуль c@1.1-SNAPSHOT
    • родительский родитель@1.1-SNAPSHOT
    • зависит от a@1.2
    • зависит от b@1.1

Зависимости, объявленные в модулях b и c, содержат минимальную версию, необходимую для компиляции модуля, которая не обязательно является текущей версией модуля или версией развертываемого модуля.

С точки зрения сборки это работает хорошо, каждый модуль может быть выпущен / обновлен по мере необходимости, однако при попытке отладки развернутого приложения в IntelliJ IDEA (версии 8 и 9 EAP), открыв pom верхнего уровня, IDEA решает, что, поскольку мы объявили зависимость от a@1.2, что каждый раз, когда мы вступаем в один из классов a, он должен открывать его из a-1.2-sources.jar, а не из текущих источников a@1.4 в проекте. Это еще более смущает тот факт, что переход в любой из классов b приводит нас к b@1.1, а не к b@1.3.

Моя первоначальная попытка обойти эту проблему состояла в том, чтобы объявить номера версий в разделе dependencyManagement родительского модуля и просто заставить субмодули наследовать версию. Это работало до такой степени, что решало проблему отладки IDEA, так как раздел dependencyManagement может указать всем на текущие версии -SNAPSHOT.

Это, к сожалению, вызывает проблему при выполнении релиза maven из-за необходимости освободить родительский pom перед выпуском модуля, но так как родитель может ссылаться на несколько находящихся в разработке -SNAPSHOTS, он не может быть освобожден, и мы заканчиваем тем, что добавляем версия ссылается на модуль pom для удовлетворения релиза.

Может показаться, что использование раздела maven dependencyManagement действительно хорошо работает, только если мы выпускаем ВСЕ комплекты одновременно, независимо от того, изменились ли они, но поскольку мы хотим управлять выпусками каждого подмодуля только тогда, когда это необходимо модель не подходит.

У меня есть подозрение, что я что-то упустил, и что комбинация dependencyManagement и диапазонов версий может удовлетворить требования, хотя я еще не видел, чтобы диапазоны версий работали должным образом.

Есть ли лучший способ? Правильный путь?

Answer 1

Я бы рекомендовал не делать их модулями, а сделать их POM независимыми. Таким образом, вам не нужно беспокоиться о попытках удовлетворить родительские зависимости POM. Поскольку они выпускаются независимо, у них действительно должны быть независимые объектные модели проекта. Думайте об Apache Commons как о шаблоне.

Answer 2

Окончательное / рабочее решение, которое мы в итоге использовали, было довольно похоже на то, с чего мы начали. Фактическая структура проекта остается прежней:

• bigsystem@1.2
  • родитель-1,1-СНАПШОТ
  • модуль a@1.4-SNAPSHOT o родительский родитель@1.1-SNAPSHOT
  • модуль b@1.3-SNAPSHOT o родительский родитель@1.1-SNAPSHOT o зависит от a1.1
  • модуль c@1.1-SNAPSHOT o родительский родитель@1.1-SNAPSHOT o зависит от a1.2 o зависит от b@1.1
  • распределение a@1.2-SNAPSHOP

Однако основные различия заключаются в том, что:

• родительский модуль не включает в себя никаких версий артефактов проекта
• отдельные модули полностью объявляют свои зависимости проекта и задают диапазон версий, т.е. [1.0.0,1.1.0)
• все модули начинают там циклы номера версии от .1, то есть 1.0.1-SNAPSHOT, это позволяет диапазону версий удовлетворяться начальными моментальными снимками (1.0.0-SNAPSHOT более ранняя, чем 1.0.0 final, поэтому не включена).
• дистрибутив pom (изначально не показывался в вопросе) идентифицирует точную версию для развертывания / включения в конкретный выпуск.
• удалить все проекты -SNAPSHOTS из локального репозитория maven при выпуске, чтобы только диапазоны выпуска пикапа (или использовать -Dmaven.repo.local = / tmp / sometemprepo для свежего локального репо)

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

Answer 3

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

Как сказал Роб, удалите свои модули a, b и т. Д. Из раздела модулей родительского POM. Во-вторых, переместите родительский POM вниз в его собственный каталог, поскольку он действительно является родственным элементом других модулей в отношении процесса сборки и выпуска. То, как вы сейчас это делаете, это скорее родитель / агрегатор.

То, что у вас есть сейчас, также не позволяет тегировать и выпускать каждый модуль по отдельности, так как тег вашего родительского POM, вероятно, излишне будет включать все подпапки модуля.

Ваша файловая структура будет выглядеть так:

• родитель
  • pom.xml
• модуль а
  • pom.xml
• модуль X
  • pom.xml

Что касается того, чего вам не хватает, dependencyManagement не очень подходит для управления версиями для внутрипроектных зависимостей. Это зависимости между модулями в агрегированной сборке. Он лучше подходит для объявления глобальных версий для внешних зависимостей.

Answer 4

Они, конечно, кажутся отдельными модулями. Какие преимущества вы получаете, разбивая их вместе, если они имеют разные зависимости, даже в рамках многомодульного проекта?