Me disculpo por la extensión de este post, pero tuve problemas para hacerlo más conciso sin presentar la imagen. Recientemente he heredado el trabajo de build-master para un proyecto de varios módulos de Maven 3.0. El problema es que la estructura del proyecto / módulos es un desastre. Desde la forma en que las cosas se almacenan actualmente en Source Control (usamos RTC) hasta la estructura de pom de los módulos, me arranco el pelo al intentar completar un ciclo completo de construcción cada vez.

Como una jerarquía de proyectos, todos los módulos se almacenan "planos"; Es decir: todo está al mismo nivel. Tengo un pom padre, y todos los módulos dependen del padre. Sin embargo, el padre está al mismo nivel que todos mis otros módulos.

Ex:

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

El pom principal define todos los módulos necesarios para construir el proyecto, así como un conjunto de propiedades para los números de versión de artefactos utilizados en los diferentes submódulos:

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

El pom de cada módulo, a su vez, depende del pom principal a través del número de artefacto del pom:

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

Para hacer las cosas aún más confusas, el nombre real del artefacto puede, o no (según el módulo), coincidir con la ruta del módulo. Por ejemplo, el módulo 1 puede estar ubicado en la rutac:\dev\MyEarProject\module1 pero tienen nombre de artefactohibernate-module. Sin embargo, debido a la forma en que se almacena en RTC, el directorio se llamamodule1 cuando se retira

La forma más fácil de construir todo, por supuesto, es entrar enc:\dev\MyEarProject\parent-pom\ y corrermvn clean deploy. Esto funciona bien cuando está en modo SNAPSHOT, ya que el repositorio SNAPSHOT permite múltiples implementaciones de la misma versión de artefacto. Pero en el modo de liberación, esto falla.

Esta estructura me está causando 2 problemas.

Cada vez que necesito hacer un cambio de versión a una propiedad en el padre, tengo que actualizar el número de versión del padre-pom y todos los módulos secundarios de la versión del padre pom y todas las versiones del módulo secundario (ya que el padre cambió).Cada vez que necesito implementar un ciclo de lanzamiento, mvn generará un error si uno de los módulos no ha cambiado desde el último ciclo y, por lo tanto, no se puede volver a implementar en el mismo repositorio (el repositorio no permite sobrescribir los artefactos existentes)

Así que estoy buscando la mejor manera de reestructurar este proyecto para evitar estos problemas. Para el pom principal, sé que puedo usar una ruta relativa para señalar al padre en su lugar. Sin embargo, dada la estructura "plana" de los módulos, ¿es este un enfoque recomendado (es decir, la ruta relativa del pom principal sería ../parent-pom/pom.xml - me parece un poco extraño)? Además, dado que el control de la versión del padre es independiente de los módulos, utilizar una ruta relativa no solo abre la puerta a una confusión adicional (es decir, no habría manera de saber qué versión del pom padre está asociada con qué versión) del submódulo).

En segundo lugar, ¿cómo puedo construir todo el oído sin encontrar los errores de despliegue que estoy teniendo? Dado que el artefacto ya existe en el repositorio, no necesito reconstruirlo y volver a desplegarlo. Intenté usar --projects pero con la cantidad de módulos involucrados, es extremadamente difícil de administrar.