Maven Родительский pom против модулей pom

кажется, есть несколько способов структурировать родительские poms в многопроектной сборке, и мне интересно, есть ли у кого-нибудь мысли о том, какие преимущества / недостатки есть в каждом пути.

самый простой способ иметь Родительский pom-это поместить его в корень проекта, т. е.

myproject/
  myproject-core/
  myproject-api/
  myproject-app/
  pom.xml

где пом.xml является родительским проектом, а также описывает модули-core-api и-app

следующий метод состоит в том, чтобы отделить родителя в свой собственный подкаталог как в

myproject/
  mypoject-parent/
    pom.xml
  myproject-core/
  myproject-api/
  myproject-app/

где Родительский pom все еще содержит модули, но они относительны, например ../ myproject-core

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

myproject/
  mypoject-parent/
    pom.xml
  myproject-core/
  myproject-api/
  myproject-app/
  pom.xml

где Родительский pom содержит любую" общую " конфигурацию(dependencyManagement, свойства и т. д.) и myproject / pom.xml содержит список модулей.

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

несколько бонусных вопросов:

  • где лучше всего определить различную общую конфигурацию, как в системе управления версиями, каталогах развертывания,общих плагинах и т. д. (Я предполагаю, что родитель, но я часто был укушен этим, и они оказались в каждом проекте, а не в общем).
  • как плагин maven-release, hudson и nexus справляются с тем, как вы настраиваете свой мультипроекты (возможно, гигантский вопрос, это больше, если кто-то был пойман, когда, как была настроена сборка мультипроекта)?

Edit: каждый из подпроектов имеет свой собственный pom.xml, я оставил его, чтобы он был кратким.

263
build-process java maven-2

4 ответов

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

если ответ да (и это случай большинства проектов, которые были упомянуты в вопросе или в комментариях), то Родительский pom нуждается в своем собственном модуле из VCS и с точки зрения Maven, и вы закончите вверх с чем-то вроде этого на уровне VCS:

root
|-- parent-pom
|   |-- branches
|   |-- tags
|   `-- trunk
|       `-- pom.xml
`-- projectA
    |-- branches
    |-- tags
    `-- trunk
        |-- module1
        |   `-- pom.xml
        |-- moduleN
        |   `-- pom.xml
        `-- pom.xml

это делает проверку немного болезненной и общий способ справиться с этим-использовать svn:externals. Например, добавьте :

root
|-- parent-pom
|   |-- branches
|   |-- tags
|   `-- trunk
|       `-- pom.xml
|-- projectA
|   |-- branches
|   |-- tags
|   `-- trunk
|       |-- module1
|       |   `-- pom.xml
|       |-- moduleN
|       |   `-- pom.xml
|       `-- pom.xml
`-- trunks

со следующим внешним определением:

parent-pom http://host/svn/parent-pom/trunk
projectA http://host/svn/projectA/trunk

проверка trunks затем приведет к следующей локальной структуре (шаблон #2):

root/
  parent-pom/
    pom.xml
  projectA/

дополнительно, вы даже можете добавить pom.xml на trunks каталог:

root
|-- parent-pom
|   |-- branches
|   |-- tags
|   `-- trunk
|       `-- pom.xml
|-- projectA
|   |-- branches
|   |-- tags
|   `-- trunk
|       |-- module1
|       |   `-- pom.xml
|       |-- moduleN
|       |   `-- pom.xml
|       `-- pom.xml
`-- trunks
    `-- pom.xml

этой pom.xml является своего рода" поддельным " pom: он никогда не выпускается, он не содержит реальной версии, так как этот файл никогда не выпускается, он содержит только список модулей. С помощью этого файла проверка приведет к такой структуре (шаблон №3):

root/
  parent-pom/
    pom.xml
  projectA/
  pom.xml

этот " хак " позволяет запускать сборку реактора из корня после проверки и делать вещи еще более удобными. На самом деле, именно так мне нравится настраивать проекты maven и репозиторий VCS для большой строит: он просто работает, он хорошо масштабируется, он дает всю необходимую гибкость.

если ответ нет (вернемся к первоначальному вопросу), тогда я думаю, что вы можете жить с шаблоном № 1 (Сделайте простейшую вещь, которая может работать).

теперь о бонусных вопросах:

  • где лучше всего определить различные общие конфигурации, как в системе управления версиями, каталоги развертывания, общие плагины и т. д. (Я предполагаю, что родитель, но я часто был укушен этим, и они оказались в каждом проекте, а не в общем).

честно говоря, я не знаю, как не дать общего ответа здесь (вроде "используйте уровень, на котором ты думаешь, есть смысл mutualize вещи"). И в любом случае дочерние poms всегда могут переопределять унаследованные настройки.

  • как плагин Maven-release, hudson и nexus справляются с тем, как вы настройте свои мультипроекты (возможно, гигантский вопрос, это больше, если кто-то был пойман, когда, как была настроена сборка мультипроекта)?

настройка, которую я использую, работает хорошо, ничего особенного упоминать.

на самом деле, мне интересно, как Maven-release-plugin имеет дело с шаблоном #1 (особенно с <parent> раздел, так как вы не можете иметь зависимости моментальных снимков во время выпуска). Это звучит как проблема курицы или яйца, но я просто не могу помните, если это работает и было слишком ленивым, чтобы проверить его.

158

из моего опыта и лучших практик Maven есть два вида "родительских помпонов"

  • "компания" Родительский pom-этот pom содержит информацию и конфигурацию вашей компании, которые наследуют каждый pom и не должны быть скопированы. Эти сведения:

    • репозитории
    • разделы управления распределением
    • общие конфигурации плагинов (например, maven-compiler-plugin source и target версии)
    • организации, разработчики и т. д.

    подготовка этого родительского pom нужно делать с осторожностью, потому что все ваши компании poms унаследуют от него, поэтому этот pom должен быть зрелым и стабильным (выпуск версии родительского pom не должен влиять на выпуск всех ваших проектов компании!)

  • второй родитель POM является многомодульным родителем. Я предпочитаю ваше первое решение - это соглашение maven по умолчанию для многомодульных проектов, очень часто представляет структуру кода VCS

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

Mutliprojects имеют структуру деревьев-так что вы не arrown до одного уровня родительского pom. Попробуйте найти подходящий проект struture для ваших нужд-классический пример, как disrtibute mutimodule проектов

distibution/
documentation/
myproject/
  myproject-core/
  myproject-api/
  myproject-app/
  pom.xml
pom.xml

несколько бонусных вопросов:

  • где лучше всего определить различную общую конфигурацию, как в системе управления версиями, каталогах развертывания,общих плагинах и т. д. (Я предполагаю, что родитель, но я часто был укушен этим, и они оказались в каждом проекте, а не в общем).

эта конфигурация должна быть разумно разделена на родительский pom "компании" и родительский POM(ы) проекта. Вещи, связанные со всем, что Вы проект перейти к" компании " родитель и это связанные с текущим проектом перейти к проекту one.

  • как плагин Maven-release, hudson и nexus справляются с тем, как вы настраиваете свои мультипроекты (возможно, гигантский вопрос, это больше, если кто-то был пойман, когда, как была настроена сборка мультипроекта)?

Родительский pom компании должен быть выпущен первым. Для multiprojectsбыл стандартных правил. Сервер CI должен знать все, чтобы правильно построить проект.

31

  1. независимый родитель-лучшая практика для совместного использования конфигурации и параметров между другими несвязанными компонентами. Apache имеет Родительский проект pom для обмена юридическими уведомлениями и некоторыми общими параметрами упаковки.

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

  3. общим шаблоном (игнорируя #1 на данный момент) является то, что проекты с кодом используют Родительский проект в качестве своего родителя, и он использует верхний уровень в качестве родителя. Это позволяет основным вещам совместно использоваться всеми, но избегает проблемы, описанной в #2.

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

  5. Apache CXF пример шаблон #2.

21

есть один маленький подвох с третьим подходом. Начиная с агрегатных POMs (myproject / pom.xml) обычно не имеют родителя вообще, они не разделяют конфигурацию. Это означает, что все эти агрегированные POMs будут иметь только репозитории по умолчанию.

это не проблема, если вы используете только плагины из Central, однако это не удастся, если вы запустите плагин с помощью формата plugin: goal из своего внутреннего репозитория. Например, вы можете иметь foo-maven-plugin с groupId org.example обеспечение гол generate-foo. Если вы попытаетесь запустить его из корня проекта с помощью команды mvn org.example:foo-maven-plugin:generate-foo, он не будет работать на агрегатных модулях (см. примечание по совместимости).

возможны несколько решений:

  1. развернуть плагин в Maven Central (не всегда возможно).
  2. укажите раздел репозитория во всех ваших агрегированных POMs (breaks сухой принципе).
  3. этот внутренний репозиторий настроен в настройки.xml (либо в локальных настройках в~/.м2/настройки.xml или в глобальных настройках в /conf / settings.XML.) Приведет к сбою сборки без этих настроек.xml (может быть хорошо для больших внутренних проектов, которые никогда не должны быть построены за пределами компании).
  4. используйте родителя с настройками репозиториев в ваших агрегированных POMs (может быть слишком много родительских POMs?).
8