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

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

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

Ex:

c:devMyEarProject
 + 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 может быть расположен в path c:devMyEarProjectmodule1 но у артефакта имя hibernate-module. Однако из-за того, как он хранится в RTC, каталог называется module1, когда он выезжал.

самый простой способ построить все, конечно, это пойти в c:devMyEarProjectparent-pom и запустить mvn clean deploy. Это прекрасно работает в режиме моментального снимка, поскольку РЕПО моментального снимка позволяет несколько развертываний одной и той же версии артефакта. Но в режиме release, это не удается.

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

1. каждый раз, когда мне нужно изменить версию на свойство в родителе, я должен обновить номер версии parent-pom и все дочерние модули версии parent pom и все дочерние модули версии самих себя (так как родитель измененный.)
2. всякий раз, когда мне нужно развернуть цикл выпуска, mvn выдаст ошибку, если один из модулей не изменился с последнего цикла и, следовательно, не может быть перераспределен в то же самое РЕПО (РЕПО не позволяет перезаписывать существующие артефакты)

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

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