Где определить свойства в мультимодульном проекте Maven?

Question

В настоящее время у меня есть следующая структура для моего проекта Foo:

foo-parent
  +- pom.xml

project-foo
  +- pom.xml
  +- module-1
  |    +- pom.xml
  |    +- ...
  +- module-2
  |    +- pom.xml
  |    +- ...
  +- ...

В foo-parent есть pom.xml, который определяет всю общую конфигурацию для моего проекта (основные зависимости,управление плагинами и т. д.).Экстернализация родительского объекта помогает мне иметь стабильную родительскую конфигурацию (это не так, если родительский объект является корнем pom.xml, который также используется для объединения всех модулей).

project-foo/pom.xml - этотолько здесь, чтобы объединить все модули, и не определяет какого-либо родителя ...

Теперь я изменяю свой проект для использования плагина релиза Maven.Таким образом, мне нужно настроить информацию <scm>.Но куда поместить эту информацию, поскольку она зависит от ветви, в которой расположен код (т. Е. Значение <scm> отличается для кода в trunk , чем в branch-X или branch-Y ).

• Решение # 1 Определить <scm> в проекте foo-parent.Таким образом, каждый модуль будет иметь эту информацию доступной.Тем не менее, у меня будет несколько версий foo-parent проекта, по одной на ветку.Это усложнит управление версиями этого родителя ...
• Solution # 2 Определите <scm> в проекте foo-parent, но добавьте параметр внутри (например, * 1037)*).Однако это просто переместит проблему: где я могу определить свойство svn.branch?
• Решение # 3 Определите <scm> в project-foo/pom.xml, который теперь будет иметь foo-parent в качестве родителя, и измените <parent> всех подмодулей на точкудо project-foo/pom.xml (то есть foo-parent > foo-root > module-X).
• Решение # 4 Определите <scm> (или svn.tag свойство) в каждом модуле.Не очень нравится ...
• Решение № 5 Есть еще идеи?

Моя точка зрения состоит в том, чтобы использовать решение № 3, ноЧто вы думаете об этом?

Спасибо.

Редактировать (относительно ответа на вопрос о хмарбайзе)

Проект foo-parent в действительности находится в подкаталоге project-foo, но не агрегируется файлом project-foo/pom.xml.Я сказал, что «извлек» его, чтобы показать, что он отделен от остальных модулей.Основной интерес заключается в том, чтобы попытаться сохранить родительский уровень как можно более стабильным, и именно поэтому я попытался отделить родительский pom от pom агрегации.

Однако, поскольку я широко использую плагин релиза Maven (нев этом проекте, но в других проектах), я думаю, что лучше не продолжать этот путь, а объединить все foo-parent/pom.xml в project-foo/pom.xml.Это облегчит управление моим проектом.

Answer 1

Если вам нравится использовать мультимодули в maven, вы должны следовать некоторым рекомендациям, что означает, во-первых, чтобы родитель был в вашей структуре, а не снаружи.Это означает:

project-foo
  +- pom.xml (This is your parent for the module-1 etc.)
  +- module-1
  |    +- pom.xml
  |    +- ...
  +- module-2
  |    +- pom.xml
  |    +- ...
  +- ...

Что можно отклониться от этого, это создать новую папку:

project-foo
  +- pom.xml 
  +- project-parent (pom.xml)
  +- module-1
  |    +- pom.xml
  |    +- ...
  +- module-2
  |    +- pom.xml
  |    +- ...
  +- ...

Но чем вы должны определить родителя, немного странного для module-1:

  <parent>
    <groupId>..</groupId>
    <artifactId>..<artifactId>
    <version>..</version>
    <relativePath>../project-parent/<relativePath>
  </parent>

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

Если вы используете "default", что является наилучшей практикой:

project-foo
  +- pom.xml (This is your parent for the module-1 etc.)
  +- module-1
  |    +- pom.xml
  |    +- ...
  +- module-2
  |    +- pom.xml
  |    +- ...
  +- ...

в вашем модуле-1 это выглядит следующим образом:

  <parent>
    <groupId>..</groupId>
    <artifactId>..<artifactId>
    <version>..</version>
  </parent>

и у вашего родителя (в данном случае).

project-foo
  +- pom.xml (This is your parent for the module-1 etc.)

вы должны определитьМодули, которые вы используете:

<modules>
  <module>module-1</module>
  <module>module-2</module>
  ..
</modules>

Кроме того, вы должны также определить ваши зависимости и pluginManagement в этом pom.

Если вы хотите иметь полный отдельный родительский pom, вы должны определитьотдельный проект, который содержит pom плюс конфигурацию scm только для этого pom и делает реальный выпуск этого pom (как артефакт jar, за исключением того, что это pom) и, конечно, версию, которую вы можете использовать в своем проекте в качестве родительского.

Подходит кточка области SCM: Единственное место для такого рода информации в многомодульной сборке находится в проекте -foo / pom.xml:

project-foo
  +- pom.xml (This is your parent for the module-1 etc.)

. Больше нигде не будет определения SCM вмодули!Более того, никогда не используйте свойства для определения области scm, просто используйте нужную информацию:

scm: svn: scm: svn: http: /// project / trunk / scm: svn: http: /// project/ trunk / scm: svn: http: /// project / trunk /

Если вы беспокоитесь о проблеме с помощью веток и т. д., вы можете решить эту проблему с помощью maven-release-plugin что дает вам возможность создать ветку с помощью:

mvn release:branch 

Исходя из этого и в процессе выпуска, URL для области SCM будет соответствующим образом изменен.Поэтому вам не нужно беспокоиться о них (никогда не используйте свойства для них, потому что они не будут работать!)

Вам также необходимо настроить область distributionManagement, чтобы определить, куда поместить SNAPSHOT и выпущенную версию вашей версии.артефакты (надеюсь, вы используете менеджер репозитория, такой как Nexus, Artifactory или Archiva?).

Я могу порекомендовать прочитать Sonatype Book для многомодульных сборок и т. д.