В этой статье мы обсудим использование родительских и агрегатных POM, а также некоторые параметры сборки, предоставляемые специалист сделать создание крупных проектов с Maven довольно легко.

Мы также хотим подчеркнуть понятие цикла выпуска и последствий для управления версиями, если вы создаете свои продукты с помощью Maven.

Давайте начнем с определения агрегатного и родительского POM, данного в Создать агрегатный проект Maven авторами из Красная шляпа :

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

Чтобы упростить построение нескольких проектов, вы можете дополнительно создать совокупный проект Maven. Он состоит из одного файла POM (совокупного POM), обычно в родительском каталоге отдельных проектов. Файл POM указывает, какие подпроекты (или модули) нужно построить, и создает их в указанном порядке.

Создать агрегатный проект Maven

Maven также поддерживает понятие родительского POM. Родительский POM позволяет вам определять отношения стиля наследования между POM. Файлы POM в нижней части иерархии объявляют, что они наследуются от определенного родительского POM. Затем родительский POM может использоваться для обмена определенными свойствами и деталями конфигурации. Создать агрегатный проект Maven

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

<проект ...> ... <groupId> de.mycorp.something </ groupId> <artifactId> что-то </ artifactId> <версия> 1.0.0-SNAPSHOT </ версия> ... <modules> <модуль> нечто-lib </ module> <модуль> нечто-домен </ module> <module> что-то веб </ module> </ modules> ... </ project>

POM является совокупным POM, поскольку он ссылается на модули. Подмодули ссылаются на это POM как на своего родителя, что делает совокупное POM также родительским POM.

<project ...> ... <parent> <groupId> de.mycorp.something </ groupId> <artifactId> что-то </ artifactId> <версия> 1.0.0-SNAPSHOT </ version> </ parent> .. . <artifactId> что-то веб </ artifactId> ... </ project>

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

В POM Best Practices Вы можете прочитать о лучших практиках, опубликованных Sonatype для некоторых хороших примеров, в которых они подробно обсуждают зависимости между проектами. Но то, что, на наш взгляд, в этих примерах не соответствует концепции жизненного цикла версий и выпусков , которые также играют важную роль в принятии решения о том, как структурировать ваши проекты.

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

Вы можете использовать разные версии для своих модулей, но это не займет у вас много времени. Если вы выпускаете проект через его совокупное родительское POM, все модули будут освобождены с их индивидуальной версией. Это нормально, - сначала подумал. Если вы посмотрите поближе, вы заметите, что версия будет увеличиваться, даже если некоторые из модулей не имеют никаких изменений вообще. При таком подходе, имея многомодульный агрегатный родительский POM, использующий разные версии для каждого подмодуля, у вас есть только возможность решить, является ли новая версия мажор, минор или микро , Но стоит ли это усилий?

В большинстве простых сценариев у вас будет меньше проблем, если вы позволите наследовать ваши подмодули родительской версии проекта и выпустить весь проект за один раз. Мы считаем, что наличие разных версий является показателем того, что модуль должен находиться в своих собственных циклах выпуска. Доказательства становятся еще более убедительными, если модуль используется и в других проектах. В этом случае вам, как правило, гораздо лучше с отдельными проектами, которые вы создаете и выпускаете сами. Это потому, что это может стать довольно громоздким, если вы хотите сделать релиз подмодуля без релиза для всего многомодульного проекта.

Авторы Создать агрегатный проект Maven прийти к аналогичному решению:

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

Это соответствует нашему наблюдению: в более крупных проектах команда пытается уменьшить ненужную сборку путем рефакторинга модулей в свои собственные проекты с собственным циклом выпуска. Монолитная сборка часто легко обрабатывается в начале проекта, когда количество модулей невелико. Вызывая любую команду сборки в корневом проекте, весь проект создается за несколько минут (если вы не создаете сайт с большим количеством отчетов). Как только количество проектов увеличивается, оно становится все более громоздким из-за увеличения времени сборки.

Некоторые могут утверждать, что они хотят

построить весь проект с помощью одного нажатия кнопки.

Но мы думаем, что это касается только небольших проектов. Что действительно нужно, так это

продукт может быть собран одним нажатием кнопки.

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

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

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

Вот как выглядит совокупный POM:

<проект ...> ... <groupId> de.mycorp.something </ groupId> <artifactId> что-то </ artifactId> <версия> 1.0.0-SNAPSHOT </ версия> ... <modules> <модуль> нечто-пом </ module> <модуль> нечто-lib </ module> <модуль> нечто-домен </ module> <модуль> что-то веб </ module> </ modules> ... </ project>

Совокупный POM больше не является родительским POM - есть новый подмодуль, который несет эту ответственность.

<project ...> ... <parent> <groupId> de.mycorp.something </ groupId> <artifactId> нечто-pom </ artifactId> <версия> 1.0.0-SNAPSHOT </ version> </ parent> ... <artifactId> что-то веб </ artifactId> ... </ project>

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

В прошлом мы сталкивались с некоторыми трудностями при сборке проектов в одиночку или в составе сборок из нескольких модулей. Но с Maven 3 эти проблемы казались историей. В своей статье Десять главных причин переехать в Maven 3 Андерс Хаммар объясняет, что Maven 3 устраняет несколько проблем с зависимостями в сборках реактора:

# 2. Maven 3 изолирует проектные зависимости и зависимости плагинов
...
# 5. Maven 3 имеет улучшенное разрешение артефактов / зависимостей

Благодаря рефакторингу логики разрешения артефактов в Maven были исправлены существующие недостатки разрешения артефактов в сборках реакторов с Maven 2.x.
...
# 7. Maven 3 имеет более интеллектуальную загрузку классов для многомодульных сборок

Некоторые проблемы все еще существуют , хотя:

1. MNG-3559 : Проблемы при создании сайта, если приложены тестовые источники.
   В качестве обходного пути позвоните на сайт установки mvn

В его переполнение стека ответ на вопрос Maven Совокупный POM с целью? Мартин Альгестен Предполагается использовать профили для вызова различных сборок.

Вот пример, который показывает, что этот совет очень удобен:

<проект ...> ... <профили> <профиль> <id> бэкэнд </ id> <модули> <модуль> что-то-lib </ module> <модуль> что-то-домен </ module> </ modules> </ profile> <profile> <id> внешний интерфейс </ id> <modules> <module> что-то веб </ module> </ modules> </ profile> <профиль> <id> все </ id> <активация> <activeByDefault> true </ activeByDefault> </ активации> <модули> <модуль> нечто-пом </ module> <модуль> нечто-lib </ module> <модуль> нечто-домен </ module> <модуль> что-то- Интернет </ module> </ modules> </ profile> </ profile> ... </ project>

В нашем примере мы можем собрать все модули одновременно,

построить только бэкэнд

mvn clean install -Pbackend

или интерфейс

mvn clean install -Pfrontend

часть.

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

Начиная с версии 2.1 Maven предоставляет несколько очень полезных опций командной строки для взаимодействия с реактором. Большинство людей используют опцию -rf, чтобы продолжить сборку с данным проектом после исправления некоторых проблем, которые приводили к сбою многомодульной сборки.

Используя совокупную POM, мы также можем построить указанный проект и все проекты в реакторе, от которых зависит:

mvn clean install - проектирует что-то-домен -am -Pbackend

Это создаст модуль домена и модуль библиотеки.

С -amd вы можете запустить противоположную сборку, которая собирает указанный проект и все проекты в реакторе, которые зависят от этого проекта. Для получения подробной информации о возможностях работы с реактором, пожалуйста, обратитесь к Maven Советы и хитрости: расширенные параметры реактора Тим О'Брайен.

Если вы не хотите, чтобы совокупный POM содержал папки подмодулей, вы можете добавить выделенный пакетный POM для своих подмодулей, например так:

• что-то-П
• что - то-партия-П
• что-то Пб
• что-то-домен
• что-то-веб

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

Содержимое пакета POM выглядит следующим образом:

<project ...> ... <artifactId> нечто-batch-pom </ artifactId> <версия> 0.1.0-SNAPSHOT </ версия> <packaging> pom </ packaging> ... <профили> ... <профиль> <id> все </ id> <активация> <activeByDefault> истина </ activeByDefault> </ активации> <модули> <модуль> ../ что-то пом <<модуль> ../ что-то- lib </ module> <module> ../ что-то-домен </ module> <module> ../ что-то-веб </ module> </ modules> </ profile> </ profile> ... </ project>

Но это не совсем Maven способ взглянуть на это. Вы можете увидеть это, как только захотите обратиться к модулю из командной строки. Название модуля: ../something-domain, а не что-то доменное, что несколько громоздко. Но необходимо однозначно идентифицировать ссылочные модули.

mvn clean install --projects ../something-domain -am -Pbackend

Если вам не нужен ни один из этих параметров, есть третий: добавьте файл POM с именем batch-pom.xml в родительскую папку и явно вызовите его из командной строки.

Имена модулей могут использоваться, как ожидается, для всех модулей в папке, а имя файла POM четко указывает причину его существования. Недостатком является то, что вы должны явно указать имя файла POM.

В этой статье приведены некоторые простые рекомендации по работе с родительскими и агрегатными POM:

1. Если ваш родительский POM также является совокупным POM, все проекты выпускаются одновременно.
2. Родительский POM (который не является совокупным POM) выпускается в своем собственном цикле и имеет отдельный номер версии.
3. Совокупный POM (который не является родительским POM) никогда не освобождается и действует только как помощник по сборке.
   1. Используйте профили для объединения проектов
   2. Используйте параметры командной строки, чтобы построить только часть проектов в реакторе.

Похожие