Eu peço desculpas pela duração deste post, mas tive dificuldade em torná-lo mais conciso sem apresentar a foto. Eu recentemente herdei o trabalho de build-master para um projeto multi-módulo maven 3.0. O problema é que a estrutura do projeto / módulos é um desastre. Desde o modo como as coisas são atualmente armazenadas no Controle de Origem (usamos o RTC) para a estrutura pom dos módulos, estou arrancando meu cabelo tentando obter um ciclo completo de construção concluído a cada vez.

Como uma hierarquia de projeto, todos os módulos são armazenados "flat"; ou seja: tudo está no mesmo nível. Eu tenho um pom pai e todos os módulos dependem do pai. No entanto, o pai está no mesmo nível que todos os meus outros 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>

O pom pai define todos os módulos necessários para construir o projeto, bem como um conjunto de propriedades para números de versão de artefatos usados ​​nos 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>

Cada pom do módulo, por sua vez, depende do pom pai através do número do artefato do pom:

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

Para tornar as coisas ainda mais confusas, o nome real do artefato pode, ou não (dependendo do módulo), corresponder ao caminho do módulo. Por exemplo, module1 pode estar localizado no caminhoc:\dev\MyEarProject\module1 mas tem nome de artefatohibernate-module. No entanto, devido à maneira como é armazenado no RTC, o diretório é chamadomodule1 quando é check-out.

A maneira mais fácil de construir tudo, é claro, é entrar emc:\dev\MyEarProject\parent-pom\ e corramvn clean deploy. Isso funciona bem no modo SNAPSHOT, já que o repositório SNAPSHOT permite várias implementações da mesma versão de artefato. Mas no modo de liberação, isso falha.

Essa estrutura está causando 2 problemas para mim.

Toda vez que eu preciso fazer uma mudança de versão para uma propriedade no pai, eu tenho que atualizar o número da versão pai-pom, e todos os módulos filhos da versão pai pom, e todos os módulos filhos da própria versão (desde que o pai mudou).Sempre que eu precisar implantar um ciclo de lançamento, o mvn lançará um erro se um dos módulos não tiver sido alterado desde o último ciclo e, conseqüentemente, não puder ser reimplantado no mesmo repo (o repo não permite substituir os artefatos existentes)

Então eu estou procurando a melhor maneira de reestruturar este projeto para evitar esses problemas. Para o pai pom, eu sei que posso usar um caminho relativo para apontar para o pai em vez disso. No entanto, dada a estrutura "plana" dos módulos, esta é uma abordagem recomendada (isto é: o caminho relativo do pai pom seria ../parent-pom/pom.xml - parece um pouco estranho para mim)? Além disso, dado que o controle de versão do pai é independente dos módulos, usar um caminho relativo não apenas abriria a porta para confusão adicional (ou seja: não haveria como saber qual versão do pom pai está associada a qual versão do submódulo).

Em segundo lugar, como posso construir a orelha inteira sem encontrar os erros de implantação que estou tendo? Como o artefato já existe no repositório, não preciso reconstruí-lo e reimplementá-lo. Eu tentei usar --projects mas com o número de módulos envolvidos, fica extremamente difícil de gerenciar.