Configuração do projeto multimódulo Maven com várias dependências diferentes

Question

Deixe-me apenas dizer isto primeiro:Eu sou novo no Maven.Dito isto, procurei, mas não encontrei respostas para a seguinte pergunta.Encontrei respostas para perguntas semelhantes, mas não para este cenário.Ou talvez eu tenha entendido mal as respostas e isso possa ser resolvido simplesmente com uma configuração de vários módulos.

Eu teria a seguinte hierarquia de dependências:

database
|  |
|  +---core
|      |  |
|      |  +---business 
|      |        |
|      |        +------App1
|      |        |
|      |        +------App2
|      |
|      +---------------App3
|
+----------------------App4

Eu gostaria de fazer com que funcionasse para que as alterações resultem apenas em novos lançamentos de quaisquer módulos/aplicativos "upstream".Este é realmente um caso simples de configuração maven de vários módulos ou preciso fazer outra coisa?

Answer 1

Se você quiser que a liberação de um componente produza uma nova versão de cada projeto, basta usar plugin de lançamento maven: http://maven.apache.org/maven-release/maven-release-plugin/.

Documentação

De acordo com o documento, isso seria:

• Verifique se não há alterações não confirmadas nas fontes
• Verifique se não há dependências SNAPSHOT
• Altere a versão nos POMs de x-SNAPSHOT para uma nova versão (serão solicitadas as versões a serem usadas)
• Transformar as informações do SCM no POM para incluir o destino final da tag
• Execute os testes do projeto nos POMs modificados para confirmar que tudo está funcionando bem
• Confirme os POMs modificados
• Marque o código no SCM com um nome de versão (isso será solicitado)
• Aumente a versão nos POMs para um novo valor y-SNAPSHOT (esses valores também serão solicitados)
• Confirme os POMs modificados

Por causa da estrutura multimódulo do maven, eles estão interligados e cada projeto seria lançado em uma nova versão.

Em poucas palavras, isso irá:

• mover versão 1.0-SNAPSHOT --> 1.1-SNAPSHOT
• etiqueta 1.0
• gerar 1.0.jar (ou guerra ou qualquer outra coisa)

Uso de plug-in

Supondo que o SCM esteja definido corretamente e o gerenciamento de repositório e distribuição configurado, basta adicionar estas linhas

<project>
  [...]
  <build>
    [...]
    <plugins>
      [...]
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-release-plugin</artifactId>
        <version>2.4.2</version>
        <!-- optional, basic format is ${project.artifactId}-${project.version}.${project.type}-->
        <configuration>
          <tagNameFormat>v@{project.version}</tagNameFormat>
        </configuration>
      </plugin>
      [...]
    </plugins>
    [...]
  </build>
  [...]
</project>

E ligue

mvn release:prepare
mvn release:perform

Herança vs Dependência

Você pode considerar as duas abordagens diferentes do Maven:

• herança, isso significa módulos pai e múltiplos/sub
• agregação, em outras palavras:uso de dependências

Em um projeto multimaven, todos os seus módulos, incluindo o pai, compartilham o mesmo ciclo de vida.Liberar um implica liberar todos e, portanto, liberar apenas um não faz sentido.

No seu caso, você não pode modificar os aplicativos 1 a 3 sem afetar o aplicativo 4.Se o App 4 depende do App 1, obviamente o App 1 não pode depender do App 4 (referências circulares não são permitidas).

Portanto, se você deseja isolar App4 e App1 em 3 ciclos de vida, não deve usar vários módulos, mas apenas compartilhar um projeto pai ou uma hierarquia de pom como corporativo > projeto principal > subprojeto (não submódulo).Depois disso, basta declarar uma dependência entre o App 4 e o App 1.(...em app4 pom.xml)

Apenas outro pensamento:o nome dos seus projetos e submódulos parece estranho.A hierarquia "clássica" é frequentemente (considerando o domínio de vários objetos de negócios para um projeto grande):

Main Project (sometimes EAR) --> POM 
|-- Business Object / DAO --> POM
|   |-- Domain 1 --> JAR
|   `-- Domain 2 --> JAR
|-- Core (depends on BO)  --> JAR
`-- IHM / Web App (depends on core)  --> WAR

Portanto, o banco de dados raramente está no topo da hierarquia.