Архитектура примера наследования и агрегирования Maven - PullRequest
Новая
       28

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

14 голосов
/ 13 января 2012

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

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

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

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

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

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

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

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

Aggregation:

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

  1. проект-апи
  2. Веб-app1
  3. Веб-app2

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

  1. проект-апи
  2. POM родительского веб-приложения

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

  1. Веб-app1
  2. Веб-app2

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

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

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

1 Ответ

12 голосов
/ 13 января 2012

Ваш подход разумен. Пара баллов:

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

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

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

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

Aggregation

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

overall
  project-api
  webapp-parent
  webapp1
  webapp2

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

overall
  project-api
  webapp-parent
    webapp1
    webapp2

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

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

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

...