Impostazione del progetto Multi Module Maven con varie dipendenze diverse

Question

Lasciami dire solo questo: sono nuovo di zecca a Maven.Detto questo ho cercato ma non ho trovato risposte alla seguente domanda.Ho trovato risposte a domande simili, non solo questo scenario.O forse ho appena frainteso le risposte e questo può essere risolto semplicemente con una configurazione del modulo Multi.

Avrei la seguente gerarchia di dipendenza:

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

.

Mi piacerebbe farlo funzionare in modo che le modifiche causino solo nuove versioni di qualsiasi modulo / app / app "a monte".Questo è davvero un semplice caso di configurazione MAVEN Multi-module o devo fare qualcos'altro?

Answer 1

Se si desidera che il rilascio di un componente produce una nuova versione di ciascun progetto, solo utilizzare maven-release-plugin : http://maven.apache.org/maven-release/maven-release-plugin/ .

Documentazione

Come da DOC, questo sarebbe:

.

.
• Verifica che non ci siano cambiamenti non combinati nelle fonti
• Verifica che non ci siano dipendenze da istantanea
• Modifica la versione nei POMS da X-Snapshot a una nuova versione (ti verrà richiesta le versioni da utilizzare)
• Trasforma le informazioni SCM nel POM per includere la destinazione finale del tag
• Eseguire i test del progetto contro i POM modificati per confermare tutto è in ordine di lavoro
• Impegna i POM modificati
• Tag Il codice in SCM con un nome di versione (questo sarà richiesto)
• Bump la versione nei POM in un nuovo valore Y-istantanea (verrà richiesto anche questi valori)
• Impegna i POM modificati

A causa della struttura del modulo Multi MAVEN, sono collegati insieme, e ciascun progetto sarebbe imbattuto in una nuova versione.

In poche parole, questa sarà:

.
• Sposta la versione 1.0-istantanea -> 1.1-istantanea
• Tag 1.0
• Genera 1.0.jar (ou guerra o qualsiasi altra cosa)

Utilizzo del plugin

Supponendo che SCM sia definito correttamente e il repository e la gestione della distribuzione configurati, basta aggiungere queste linee

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

mvn release:prepare
mvn release:perform

.

Ereditarietà VS dipendenza

Puoi considerare i due differenti Approcchi di Maven:

.
• Ereditarietà, ciò significa genitore e multi / sub moduli
• Aggregazione, in altre parole: uso delle dipendenze

In un progetto multi-maven, tutti i tuoi moduli, incluso il genitore, condividono lo stesso ciclo di vita. Rilasciando uno implica che rilascia tutto, e così, rilasciando solo uno è un non senso.

Nel tuo caso, non è possibile modificare l'app da 1 a 3 Whithout Impatti sull'app 4. Se APP 4 dipende dall'app 1, ovviamente l'app 1 non può dipendere dall'app 4 (i riferimenti circolari non sono consentiti).

Quindi, si desidera isolare i cicli di vita APP4 e APP1 a 3, non è necessario utilizzare i multi-moduli, ma semplicemente condividere un progetto genitore o un hierachy di POM come il progetto principale> Project Sub (non sottomesso). Dopodiché, dichiarare una dipendenza tra app 4 e app 1. (... in app4 pom.xml)

Solo un altro pensiero: il nome dei tuoi progetti e dei tuoi sottomodi suona strani. La gerarchia "classica" è spesso (considerando il dominio dell'oggetto multi business per un grande progetto):

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

.

Quindi, il database è raramente nella parte superiore della gerarchia.