Архитектура наследования и агрегации Maven

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

Настройка сцены:

Существует 3 существующих на основе кода проектов Maven, разработанных той же командой.
1 проект - это API, позволяет вызвать project-api.
Другие 2 проекта - это веб-приложения, которые используют project-api. Позволяет называть их web-app1 и web-app2.

Все три проекта имеют пару базовых зависимостей, таких как log4j и junit. Кроме того, web-app1 и web-app2 зависят от project-api, а также совместно используют ряд дополнительных общих зависимостей между ними.

Я читал http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html, я просто хочу подтвердить, что я понимаю лучшую практику.

Наследование:

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

Будет ли иметь смысл создать еще один родительский POM, который включает зависимости (управление зависимостями), которые являются общими для web-app1 и web-app2, и наследуют только этот веб-приложение и веб-приложение2. Я думаю, что этот POM (позволяет назвать его родительским POM веб-приложения) должен быть дочерним POM родительского POM организационного уровня.

Aggregation:

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

Проект-апи
Веб-app1
Веб-app2

Означает ли это, что организационный родительский POM объявит модули:

Проект-апи
родительский веб-приложение POM

И родительский POM веб-приложения объявит модули:

Веб-app1
Веб-app2

Обратите внимание, что родительский POM веб-приложения и организационный родительский POM не имеют никакого связанного кода. Я считаю, что это нормально, отмечая: "На самом деле, в мире Maven, проект не должен содержать никакого кода вообще, а всего лишь pom.xml". взято из http://maven.apache.org/pom.html.

Наконец, как мне обеспечить соблюдение порядка сборки, который мне нужен? Например. Создание организационной родительской POM приведет к созданию проекта-api, и эта последняя сборка будет использоваться при создании web-app1 и web-app2?

Надеюсь, это не слишком смущает, с удовольствием прояснит, требуется ли дополнительная информация. Не стесняйтесь сказать мне, если я полностью ошибаюсь! Спасибо.

Ответ 1

Ваш подход разумный. Несколько пунктов:

Организационный уровень POM

Да для настроек среды и всеобъемлющей информации о проекте, а не для зависимостей.

Проекты должны явно перечислять все их зависимости и не полагаться на их наследование (IMHO). Это означает, что вам нужно несколько раз объявить свой регистратор, но это еще больше избавит вас от боли. (Конечно, вы можете использовать отдельный проект POM для группировки зависимых зависимостей и, следовательно, обычно указанных вместе, например, пример спящего режима в вашей ссылке). Если вы хотите централизовать версии зависимостей, вы можете поместить раздел dependencyManagement в родительский POM, что означает, что вы все еще объявляете зависимость в дочернем проекте, но версия исходит от родителя, что обеспечивает согласованность. Дети, которые не заявляют о зависимости, не заканчивают его вообще.

Наличие webapp-родителя - хорошая идея, если у них есть дублированные плагины, конфигурация и т.д. Если они используют общий код, вы можете добавить еще один проект webapp-common, который построен как банку, на которую могут повлиять другие два. Его зависимости будут транзитивно включены, так что естественное место для общих зависимостей будет идти.

Агрегация

webapp-parent не обязательно должен быть как родителем, так и агрегатором, если вам не нужно часто создавать webapp1 и webapp2, но не project-api в одно и то же время. Вы можете просто поместить все проекты в качестве модулей общего родителя. Структура вашего каталога может выглядеть как

overall
  project-api
  webapp-parent
  webapp1
  webapp2

или если вы предпочитаете свое первоначальное предложение, которое также прекрасно

overall
  project-api
  webapp-parent
    webapp1
    webapp2

Более важно следить за макетом проекта с течением времени и рефакторировать, когда это необходимо.

Порядок сборки

Maven достаточно умен, чтобы строить модули в правильном порядке, пока вы объявляете зависимости.