Я извиняюсь за длину этого поста, но мне было трудно сделать его более кратким без представления картинки. Недавно я унаследовал работу build-master для многомодульного проекта maven 3.0. Проблема в том, что структура проекта / модулей является катастрофой. От того, как все в настоящее время хранится в Source Control (мы используем RTC), до структуры pom модулей, я рву голову, пытаясь каждый раз завершить полный цикл сборки.

В соответствии с иерархией проекта все модули сохраняются «плоскими»; т.е. все на одном уровне. У меня есть родительский pom, и все модули зависят от родительского. Тем не менее, родитель находится на том же уровне, что и все мои другие модули.

Пример:

<code>c:\dev\MyEarProject
 + parent-pom
   - pom.xml
 + module1
   - pom.xml (depends on parent-pom)
   - src
   -   main
   -     ...
 + module2
   - pom.xml (depends on parent-pom)
   - src
   -   main
   -     ...
 + module3
   - pom.xml (depends on parent-pom)
   - src
   -   main
   -     ...
</code>

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

<code><modules>
  <module>../module1</module>
  <module>../module2</module>
  <module>../module3</module>
</modules>

<properties>
    <org.springframework.version>3.0.5.RELEASE</org.springframework.version>
    <slf4j.version>1.6.4</slf4j.version>
    <repositoryAddress>${snapshots.repo.url}</repositoryAddress>
    <my.hibernate-module.dao.impl>1.2.3</my.hibernate-module.dao.impl>
    <my.hibernate-module.dao.api>1.2.3</my.hibernate-module.dao.api>
</properties>
</code>

Pom каждого модуля, в свою очередь, зависит от родительского pom через номер артефакта pom:

<code><parent>
    <groupId>com.cws.cs.lendingsimulationservice</groupId>
    <artifactId>parent-pom</artifactId>
    <version>1.0.6</version>
</parent>
</code>

Чтобы сделать вещи еще более запутанными, фактическое имя артефакта может или не может (в зависимости от модуля) соответствовать пути к модулю. Например, модуль1 может быть расположен в путиc:\dev\MyEarProject\module1 но есть имя артефактаhibernate-module, Однако из-за того, как он хранится в RTC, каталог называетсяmodule1 когда это проверено.

Конечно, самый простой способ построить все - этоc:\dev\MyEarProject\parent-pom\ и бегиmvn clean deploy, Это прекрасно работает в режиме SNAPSHOT, поскольку репозиторий SNAPSHOT допускает несколько развертываний одной и той же версии артефакта. Но в режиме релиза это не получается.

Эта структура вызывает у меня 2 проблемы.

Everytime I need to make a version change to a property in the parent, I have to update the parent-pom version number, and all the child modules parent pom's version, and all the child modules version themselves (since the parent changed). Whenever I need to deploy a release cycle, mvn will throw an error if one of the modules has not changed since the last cycle and consequently cannot be redeployed to the same repo (the repo does not allow overwriting existing artifacts)

Поэтому я ищу лучший способ реструктуризации этого проекта, чтобы избежать этих проблем. Я знаю, что для родительского pom я могу использовать относительный путь, чтобы указать на родителя. Тем не менее, учитывая «плоский» Структура модулей, это рекомендуемый подход (то есть: относительный путь родительского pom будет ../parent-pom/pom.xml - мне кажется немного странным)? Кроме того, учитывая, что управление версиями родительского элемента не зависит от модулей, использование относительного пути не просто откроет дверь для дополнительной путаницы (т. Е. Не было бы способа узнать, какая версия родительского pom связана с какой версией субмодуля).

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