Creazione di un modulo multi-modulo creazione e rilascio di singoli moduli in modo indipendente?

Question

Attualmente sto lavorando per ottimizzare una generazione di un progetto Maven multi-modulo. Il progetto consiste di circa 90 moduli Maven. In generale ci sono alcune librerie trasversali che compongono il nucleo e poi ci sono circa 15 "moduli applicativi" che costituiscono l'intera applicazione (Che viene poi distribuito come in una GUERRA)

Ora in generale l'intero progetto ha un versione principale "2.5" quindi quando una nuova release principale viene eseguita tutti i "moduli dell'applicazione" hanno la stessa versione "2.5.0". Fin qui tutto bene.

Se un modulo ha un bug che deve essere corretto o deve essere migliorato, deve essere rilasciata una nuova versione di quel "modulo dell'applicazione". Quindi, ad esempio, il modulo A ha un bug corretto, quindi A.jar dovrebbe essere nella versione "2.5.1" mentre il resto dovrebbe essere ancora "2.5.0".

genitore (2.5.0-SNAPSHOT - Modulo A (2.5.1-SNAPSHOT) - Modulo B (2.5.0-SNAPSHOT) - Modulo C (2.5.2-SNAPSHOT) - Guerra (2.5. 3-SNAPSHOT) < - 3 alla fine, perché C aveva 2 ri-rilasci e A uno ed è stato rilasciato dopo ogni rilascio del modulo per semplicità

Ci siamo accontentati di gestire le versioni degli artefatti nel master pom così non È necessario aggiornare le versioni di dipendenza di ciascun artefatto dopo aver rilasciato un modulo.

Così ora ogni volta che un "modulo di applicazione" aggiornato è pronto, usiamo il software rilascia il plugin per eseguire il rilascio di quel modulo (Stiamo rilasciando un modulo, non l'intero progetto). Quindi diciamo che stiamo rilasciando il modulo A nella versione 2.5.4, con il risultato che A.jar viene distribuito come versione 2.5.4 e finendo aggiornando il codice del modulo in 2.5.5-SNAPSHOT.

Al termine, è necessario aggiornare la versione nel master pom, quindi tutti i moduli continuano a fare riferimento alla versione corretta.

grazie alla sezione dependencyManagement del maestro pom, se io costruisco il modulo guerra, si preleva automaticamente la nuova versione del modulo A.

Ora viene la parte difficile: non appena tutti i moduli vengono rilasciati, dovrebbe essere rilasciata una nuova versione dell'applicazione Web. Questo dovrebbe contenere tutti i Moduli non modificati così come quelli appena rilasciati. Attualmente sto lottando su come farlo. Se dipendo dalla versione genitore dei poms, la versione conterrà le versioni SNAPSHOT (tutte le versioni con incremento troppo alto), che io e il plugin di rilascio non consentono.

Quale sarebbe la soluzione migliore per questo dilemma?

Ho avuto un'idea di out-source della gestione delle dipendenze su un pom separato, che viene poi importato nel master dependomsManagement utilizzando l'ambito "import".

Questa specie di szenario è un'idea stupida? Esistono alternative allo sviluppo e alla manutenzione di una grande applicazione multi-modulo come questa? Non è possibile avere semplicemente tutte le versioni sincronizzate utilizzando il plugin di rilascio sull'intero progetto, poiché l'applicazione è grande e le applicazioni client devono caricare versioni di moduli aggiornate. Alcuni dei nostri clienti hanno connessioni molto lente, quindi distribuire tutti i moduli ogni volta li renderebbe davvero infelici.

aiuto molto apprezzato,

Chris

Answer 1

Bene, mi è venuta una soluzione per il mio problema. È un mix di una piccola patch per il plug-in releaste e un plugin Jenkins per gestire la configurazione della linea di comando piuttosto intensa necessaria.

Descrizione del processo di rilascio: https://dev.c-ware.de/confluence/display/PUBLIC/Releasing+modules+of+a+multi-module+project+with+independent+version+numbers

Descrizione del Plugin Jenkins: https://dev.c-ware.de/confluence/display/PUBLIC/Developing+a+Jenkins+Plugin+for+the+Maven+Release+Plugin

codice del Plugin: https://github.com/chrisdutz/jenkins-release-plugin

Answer 2

Prima di tutto, è importante rendersi conto che i numeri di versione, pur importante per la gestione delle dipendenze, sono del tutto arbitrario. Almeno, la forma del numero di versione è arbitraria (sì, sono a conoscenza di the syntax for Maven version ranges, che non ho mai sentito di nessuno che usi). Alcuni progetti OSS eliminano completamente i numeri di versione "tradizionali" e utilizzano solo versioni o date del repository SVN per il controllo delle versioni.

Una possibilità è quella di non avere una versione "wide-progetto", e piuttosto consentire a ciascuno dei componenti avere diversi numeri di versione. Sento che questa è una soluzione completamente accettabile.

Un'altra soluzione è rilasciare utilizzando le dipendenze dello snapshot. Non sei "presunto" per farlo, ma nulla ti impedisce di codificare a fondo la versione dello snapshot (che è incredibilmente prolissa e tempestiva). Niente tranne lo spettro di build irripetibili, comunque.

Se è necessario disporre di tutti i componenti hanno lo stesso numero di versione, suggerisco che incorpora un numero di build nella componente minore della vostra versione del progetto.

In questo approccio, è possibile utilizzare lo Maven Build Number plugin per distinguere versioni incrementali all'interno di una versione come descritto in questa domanda: Can I set the project version with a buildnumber-maven-plugin?.

nota si sarebbe solo fare questo in un profilo "versione finale" che viene utilizzato solo dalla vostra build server (o dal tecnico build).

Version Numbers plugin è anche tuo amico qui.

Il flusso di lavoro release finale sarebbe qualcosa di simile al seguente:

1. Inizia con la versione 2.5.5-SNAPSHOT.
2. mvn versions:set -DnewVersion 2.5.5.
3. Confida e tagga il tuo rilascio (o crea un ramo - qualunque sia la tua strategia qui).
4. mvn deploy -Prelease che attiva il "profilo di rilascio" che aggiunge il numero di build per il manufatto finalName.
5. mvn versions:set -DnewVersion 2.5.5-SNAPSHOT.
6. Conferma la versione "post-rilascio".

Incrementare alla versione 2.5.6, 2.6.0 ecc. Quando si dispone di una versione veramente "importante".

Buona fortuna!

Answer 3

Ieri sera mi sono reso conto che l'accumulo ho abbozzate nella mia interrogazione aveva un altro grosso problema: I moduli hanno dipendenze tra di loro e questi non sarebbero gestite dal plugin di rilascio. Queste dipendenze SNAPSHOT farebbero fallire il plugin (che è buono).

Quindi ho appena avuto un'altra idea che potrebbe risolvere i miei problemi: Creerei due artefatti di maven pom "versions-dev" e "versions-rel" che contengono una sezione dependencyManagement che definisce le versioni dev e rel. Nel mio master pom ora creo due profili "sviluppo" (attivo di default) e "rilascio" che deve essere attivato manualmente.Questi profili contengono una sezione dependencyManagement e ciascuno importa il dependencyManagement della corrispondente artefigurazione versione-pom utilizzando l'ambito "import".

Ora per una versione dovrebbe essere necessario eseguire le seguenti operazioni: - Aggiornare le versioni rel e versioni-dev alle nuove versioni. - Commit - Tag - eseguire il rilascio: eseguire bersaglio del rilascio del plugin

C'è ancora una cosa che potrebbe causare problemi: Supponendo che tutti i moduli sono stati modificati, ma solo uno dovrebbero essere inclusi in una nuova release, allora questo approccio ridistribuirebbe anche tutti i moduli, anche quelli che non volevo rilasciare. Ciò farebbe sì che le versioni modificate vengano distribuite con la stessa versione delle versioni rilasciate in precedenza. Ora potrei evitarlo non rilasciando il progetto principale, ma solo i singoli moduli. Se tuttavia fosse possibile distribuire solo quelle versioni che non sono già state implementate, renderebbe il processo di rilascio molto più semplice.

Eventuali suggerimenti, obiezioni, cose che ho dimenticato?

Chris