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

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

По мере развития иерархии проекта все модули хранятся «в плоском виде»; то есть: все на том же уровне. У меня есть родительский pom, и все модули зависят от родителя. Однако родитель находится на том же уровне, что и все остальные мои модули.

Пример:

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
   -     ...

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

<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>

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

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

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

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

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

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

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

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