Как я правильно устанавливаю проект Знатока мультимодуля со скользящими циклами выпуска
Применение UML и Шаблонов Craig Larman.
заголовок книги является немного вводящим в заблуждение; это заключает сделку с UML и шаблонами, но это покрывает настолько больше. Подзаголовок книги говорит Вам немного больше: Введение в Объектно-ориентированный Анализ и проектирование и Итерационную разработку.
4 ответа
Окончательное / рабочее решение, которое мы в итоге использовали, было довольно похоже на то, с чего мы начали. Фактическая структура проекта остается прежней:
- bigsystem@1.2
- parent-1.1-SNAPSHOT
- модуль a@1.4-SNAPSHOT o от родителей parent@1.1-SNAPSHOT
- module 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 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 для свежего локального репо)
Это делает каждый модуль более автономным и дает нам свободу выпускать и развертывать новые версии артефактов нашего проекта с минимальными усилиями.
Я бы рекомендовал не делать их модулями, а сделать их POM независимыми. Таким образом, вам не нужно беспокоиться о попытках удовлетворить родительские зависимости POM. Поскольку они выпускаются независимо, они действительно должны иметь независимые объектные модели проекта. Думайте об Apache Commons как о шаблоне.
Они определенно кажутся отдельными модулями. Какие выгоды вы получаете, объединяя их вместе, если у них разные зависимости, даже в рамках многомодульного проекта?
Я думаю, что проблема с IDEA возникает из-за того, что вы используете корневой POM в своем источнике структура для выполнения двух вещей, которые в Maven обычно исключают друг друга. Сначала вы используете POM как место для хранения общей информации о конфигурации для несвязанных (с точки зрения сборки) проектов Maven. Во-вторых, вы используете POM как агрегатор для своей сборки. Вы можете делать каждый из них, не делая другого.
Как сказал Роб, удалите проекты модулей a, b и т. Д. Из раздела модулей родительского POM. Во-вторых, переместите родительский POM вниз в его собственный каталог, поскольку он действительно является родственником других модулей в отношении вашего процесса сборки и выпуска.
- pom.xml
- pom.xml
- pom.xml
Что касается того, чего вам не хватает, dependencyManagement не совсем подходит для управления версиями для внутрипроектных зависимостей. Это зависимости между модулями в агрегированной сборке. Он больше подходит для объявления глобальных версий для внешних зависимостей.