Come si configura correttamente un progetto Maven multi-modulo con cicli di rilascio scorrevoli

Question

Sto cercando di elaborare il modo migliore per impostare il nostro progetto Apache Maven multi-modulo in un modo che consenta cicli di rilascio disparati dei moduli e non presenti problemi di dipendenza durante il debug del progetto.

Al momento disponiamo di un'installazione simile a:

• bigsystem@1.2
  • genitore-1.1-SNAPSHOT
  • modulo a@1.4-SNAPSHOT
    • parentato da parent@1.1-SNAPSHOT
  • modulo b@1.3-SNAPSHOT
    • parentato da parent@1.1-SNAPSHOT
    • dipende da a@1.1
  • modulo c@1.1-SNAPSHOT
    • parentato da parent@1.1-SNAPSHOT
    • dipende da a@1.2
    • dipende da b@1.1

Le dipendenze dichiarate nei moduli bec contengono la versione minima richiesta per compilare il modulo, che non è necessariamente la versione corrente del modulo, o la versione del modulo da distribuire.

Dal punto di vista della compilazione funziona bene, ogni modulo può essere rilasciato / aggiornato secondo necessità, tuttavia quando si tenta di eseguire il debug dell'applicazione distribuita in IntelliJ IDEA (versioni 8 e 9 EAP) dopo aver aperto il pom di livello superiore, IDEA decide che dal abbiamo dichiarato una dipendenza da a@1.2, che ogni volta che entriamo in una delle classi di a, dovrebbe aprirla da a-1.2-sources.jar piuttosto che dalle attuali fonti a@1.4 nel progetto. Ciò è ulteriormente confuso dal fatto che entrare in una delle classi di b ci porta a b@1.1 anziché a b@1.3.

Il mio tentativo iniziale di aggirare il problema è stato quello di dichiarare i numeri di versione nella sezione Gestione delle dipendenze del padre principale e solo i moduli secondari ereditano la versione. Ciò ha funzionato al punto di risolvere il problema di debug IDEA in quanto la sezione dependencyManagement può indirizzare tutti alle attuali versioni -SNAPSHOT.

Questo purtroppo causa un problema quando si esegue un rilascio maven a causa della necessità di rilasciare il pom padre prima di rilasciare il modulo, ma poiché il padre può riferirsi a più -SNAPSHOTS in sviluppo non può essere rilasciato e finiamo per aggiungere la versione fa riferimento ai moduli pom per soddisfare il rilascio.

Sembrerebbe che l'uso della sezione Gestione delle dipendenze di maven funzionerebbe davvero bene solo se stessimo rilasciando TUTTI i bundle allo stesso tempo, indipendentemente dal fatto che siano cambiati, ma poiché vogliamo gestire le versioni di ciascun sottomodulo solo quando necessario il modello non sembra adattarsi.

Ho il sospetto che mi manchi qualcosa e che una combinazione di dipendenzaGestione e intervalli di versioni potrebbe soddisfare i requisiti, anche se devo ancora vedere che gli intervalli di versioni funzionano correttamente.

C'è un modo migliore? Un modo corretto?

Answer 1

La soluzione finale / operativa che abbiamo finito per usare era abbastanza simile a quella con cui avevamo iniziato. L'attuale struttura del progetto rimane la stessa:

• bigsystem@1.2
  • genitore-1.1-SNAPSHOT
  • modulo a@1.4-SNAPSHOT   o genitore di parent@1.1-SNAPSHOT
  • modulo b@1.3-SNAPSHOT   o genitore di parent@1.1-SNAPSHOT   o dipende da a@1.1
  • modulo c@1.1-SNAPSHOT   o genitore di parent@1.1-SNAPSHOT   o dipende da a@1.2   o dipende da b@1.1
  • distribuzione a@1.2-SNAPSHOP

Tuttavia le differenze principali sono:

• il modulo padre non include alcuna versione di artefatti di progetto
• i singoli moduli dichiarano completamente le dipendenze del proprio progetto e specificano un intervallo di versioni, ovvero [1.0.0,1.1.0)
• tutti i moduli iniziano lì cicli di numeri di versione da .1, ovvero 1.0.1-SNAPSHOT, ciò consente di soddisfare l'intervallo di versioni con gli snapshot iniziali (1.0.0-SNAPSHOT è precedente alla 1.0.0 final, quindi non incluso).
• distribution pom (inizialmente non mostrato in questione) identifica la versione esatta da distribuire / includere in una versione specifica.
• elimina tutti i progetti -SNAPSHOTS dal repository di Maven locale quando viene rilasciato in modo da rilasciare solo i rilasci di intervalli (oppure usa -Dmaven.repo.local = / tmp / sometemprepo per un nuovo repository locale)

Questo rende ogni modulo più autonomo e ci dà la libertà di rilasciare e distribuire nuove versioni dei nostri artefatti del progetto con il minimo sforzo.

Answer 2

Consiglierei di non renderli moduli, ma rendere indipendenti i loro POM. In questo modo non devi preoccuparti di provare a soddisfare le dipendenze POM dei genitori. Dal momento che sono rilasciati in modo indipendente, dovrebbero davvero avere modelli di oggetti di progetto indipendenti. Pensa ad Apache Commons come modello.

Answer 3

Penso che il problema con IDEA insorga perché stai usando il root POM nella tua struttura sorgente per fare due cose che si escludono a vicenda in Maven. Innanzitutto si utilizza POM come posizione per memorizzare informazioni di configurazione comuni per progetti Maven non correlati (dal punto di vista della costruzione). In secondo luogo stai usando il POM come aggregatore per la tua build. Puoi fare ognuno di questi senza fare l'altro.

Come ha detto Rob, rimuovere i progetti del modulo a, b, ecc. dalla sezione dei moduli del POM principale. In secondo luogo, sposta il tuo POM principale nella sua directory poiché è davvero un fratello degli altri moduli rispetto al tuo processo di compilazione e rilascio. Il modo in cui lo hai ora, è più un genitore / aggregatore.

Il modo in cui lo hai ora non si presta nemmeno a taggare e rilasciare ogni modulo singolarmente poiché un tag del tuo POM genitore probabilmente includerebbe inutilmente tutte le sottocartelle del modulo.

La struttura del tuo file sarebbe simile a:

• genitore
  • pom.xml
• modulo a
  • pom.xml
• modulo X
  • pom.xml

Per quanto riguarda ciò che ti manca, dependencyManagement non è molto adatto a gestire le versioni per dipendenze all'interno del progetto. Cioè dipendenze tra i moduli all'interno di una build aggregata. È più adatto per dichiarare versioni globali per dipendenze esterne.

Answer 4

Sembrano certamente moduli separati. Quali vantaggi stai ottenendo frantumandoli insieme se hanno dipendenze diverse, anche all'interno del progetto multi-modulo?