Maven consulenza in materia di controllo delle versioni di un grande progetto e la prevenzione delle versioni contenenti espressioni

Question

sto guardando ristrutturazione di un grande progetto di Maven ...

Una panoramica di base del nostro attuale struttura:

build [MVN plugins, third party dependency management]:5.1 
    NRW Utils:6.0.0.0-beta12-SNAPSHOT 
     server-utils:6.0.0.0-beta12-SNAPSHOT 
     ... 
    CMW Root:6.0.0.0-beta12-SNAPSHOT 
     cmw-webapp:6.0.0.0-beta12-SNAPSHOT 
     cmw-core [dependencies on NRW Utils]:6.0.0.0-beta12-SNAPSHOT 
     ... 
    NRW Root :6.0.0.0-beta12-SNAPSHOT 
     nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-beta12-SNAPSHOT 
     ... 

il motivo per il cambiamento:

la dimensione di ogni modulo collettiva (cioè NRW Utils, CMW radice e NRW Root) è sempre più grande e la Buil d processo sta iniziando a prendere una quantità insopportabile di tempo (~ 4 ore a volte).

Il nuovo piano:

build [MVN plugins, third party dependency management]:5.1 
    NRW Utils:6.0.0.0-NU-beta4-SNAPSHOT 
     server-utils:6.0.0.0-NU-beta4-SNAPSHOT 
     ... 
    CMW Root:6.0.0.0-CMW-beta12-SNAPSHOT 
     cmw-webapp:6.0.0.0-CMW-beta12-SNAPSHOT 
     cmw-core [dependencies on NRW Utils]:6.0.0.0-CMW-beta12-SNAPSHOT 
     ... 
    NRW Root :6.0.0.0-NRW-beta9-SNAPSHOT 
     nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-NRW-beta9-SNAPSHOT 
     ... 

Abbiamo iniziato l'introduzione di 'chiavi' nella versione di distinguere tra diversi 'moduli collettivi' e quindi possono facilmente eseguire versioni a gradini. Inoltre, i nostri moduli di utilità sono molto più stabili, quindi potremmo non richiedere quasi tutte le versioni beta - ora non vi è alcuna restrizione sulla sincronizzazione dei numeri beta.

Vale anche la pena notare che ci sono in realtà 5 diversi "moduli collettivi" (non solo 3) tutti da costruire con diverse versioni (contraddistinte da chiavi uniche) ed è per questo che ho pensato che sarebbe stato bello avere un luogo centralizzato per le versioni, al contrario delle proprietà duplicate in 5 POM differenti.

Il problema si trova ora nel contenuto dei file POM quando si definiscono dipendenze su moduli in un diverso 'modulo collettivo' di una versione diversa.

La soluzione proposta alla dipendenza la gestione delle versioni:

build [MVN plugins, third party dependency management]:5.1 
    nrw-version-management:6.0.0.0-beta-SNAPSHOT 
     [contains properties defining latest versions of each collective module] 
     NRW Utils:6.0.0.0-NU-beta4-SNAPSHOT 
     server-utils:6.0.0.0-NU-beta4-SNAPSHOT 
     ... 
     CMW Root:6.0.0.0-CMW-beta12-SNAPSHOT 
     cmw-webapp:6.0.0.0-CMW-beta12-SNAPSHOT 
     cmw-core [dependencies on NRW Utils]:6.0.0.0-CMW-beta12-SNAPSHOT 
     ... 
     NRW Root :6.0.0.0-NRW-beta9-SNAPSHOT 
     nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-NRW-beta9-SNAPSHOT 
     ... 

NRW-versione-management (pom.xml):

... 
<parent> 
    <groupId>com.project</groupId> 
    <artifactId>build</artifactId> 
    <version>5.1</version> 
</parent> 
<groupId>com.project</groupId> 
<artifactId>nrw-versions-manager</artifactId> 
<version>6.0.0.0-beta-SNAPSHOT</version> 
<name>Version Maven Properties</name> 
<description>A centralised place for all module property versions</description> 
<packaging>pom</packaging> 
<properties> 
    <nrw.utilities.version>6.0.0.0-NU-beta4-SNAPSHOT</nrw.utilities.version> 
    <nrw.cmw.version>6.0.0.0-CMW-beta12-SNAPSHOT</nrw.cmw.version> 
    <nrw.version>6.0.0.0-NRW-beta9-SNAPSHOT</nrw.version> 
</properties> 
... 

CMW Root (pom.xml):

... 
<parent> 
    <groupId>com.project</groupId> 
    <artifactId>nrw-versions-manager</artifactId> 
    <version>${nrw.core.version}</version> 
    ... 
</parent> 
<groupId>com.project</groupId> 
<artifactId>CMW-root</artifactId> 
<version>6.0.0.0-CMW-beta12-SNAPSHOT</version> 
<packaging>pom</packaging> 
<dependencyManagement> 
    <dependencies> 
     ... 
     <dependency> 
      <groupId>${project.groupId}</groupId> 
      <artifactId>server-utils</artifactId> 
      <version>${nrw.utilities.version}</version> 
     </dependency> 
     ... 
</dependencyManagement> 
<profiles> 
    <profile> 
     <id>all</id> 
     <modules> 
      <module>cmw-webapp</module> 
      <module>cmw-core</module> 
      ... 
     </modules> 
    </profile> 
    ... 
</profiles> 
... 

N.B. la proprietà $ {nrw.core.version} sarà quindi impostata su 6.3.0.0-beta-SNAPSHOT per una build di istantanee tramite argomenti della riga di comando (o un valore di proprietà predefinito).

Un processo di rilascio possibile (per 6.0.0.0):

1. compilare il modulo 5.1 Build, se non già costruito
2. Corporatura NRW-versione-gestione 6.0.0.0 (per evitare le dipendenze istantanee - tuttavia immobili sono ancora stati cambiati)
3. Corporatura NRW Utils 6.0.0.0-NU args cmd: -Dnrw.core.version = 6.0.0.0
4. costruire CMW Root 6.0.0.0-CMW args cmd: -Dnrw. core.versi on = 6.0.0.0 -Dnrw.utilities.version = 6.0.0.0-NU
5. Build NRW Root 6.0.0.0-NRW cmd args: -Dnrw.core.version = 6.0.0.0 -Dnrw.utilities.version = 6.0 .0.0-NU -Dnrw.cmw.version = 6.0.0.0-CMW
6. Re-build nrw-version-management 6.0.0.0 per repository cmd args: -Dnrw.core.version = 6.0.0.0 -Dnrw.utilities.version = 6.0.0.0-NU -Dnrw.cmw. versione = 6.0.0.0-CMW
7. Build-versione-gestione nrw 6.1.0.0-beta-SNAPSHOT con le nuove versioni dev e file di aggiornamento POM

Il problema:

Il processo di generazione sembra prolisso, in particolare per quanto riguarda il modulo di gestione della versione nrw. Inoltre, ho iniziato a vedere questo avvertimento:

'versione' contiene un'espressione, ma dovrebbe essere una costante

E dopo aver fatto qualche indagine ora capisco le espressioni non sono raccomandati quando si impostano le versioni (quando si specifica un POM genitore):

• Warning on using project.parent.version as the version of a module in Maven 3
• Maven: property substitution not done for /project/version tag of pom?
• http://maven.40175.n5.nabble.com/Pom-Parent-Version-Properties-td124576.html

Le domande:

• Posso ignorare questo avviso? Alcuni post stanno iniziando a suggerire che potrebbe essere semplicemente accettabile specificare le versioni padre POM usando le proprietà.
• Questo approccio generale è convenzionale? O imperfetto?
• Ci sono soluzioni migliori per affrontare la ristrutturazione di questo progetto in crescita?

Grazie in anticipo.

Answer 1

Non credo che attenersi a una singola versione dell'intero progetto sia fattibile in questa fase, dato che il processo di compilazione richiede così tanto tempo (l'altro giorno ha fallito dopo 7 ore !!).

Tuttavia, i due link qui sotto non rispondono completamente alla mia domanda, ma sono sempre lì:

• How to share common properties among several maven projects?
• How do I tell Maven to use the latest version of a dependency?

Answer 2

I vantaggi di disporre di una singola versione per tutti i sottomoduli è la semplicità, un vantaggio che non dovrebbe essere sottovalutato.

Si dovrebbe infatti chiedersi più volte se si vuole veramente dipendere da diverse versioni di moduli nella stessa gerarchia. Come hai sottolineato, il rilascio diventa ingombrante.

Gestendo le relazioni in modo standardizzato con una versione singola e distribuendo sul repository locale dopo le build di successo, dovresti essere in grado di utilizzare la gestione delle dipendenze come previsto.

Se si ristruttura il progetto in modo che aderisca alle convenzioni del plug-in di rilascio, il rilascio diventa un gioco da ragazzi.

Answer 3

Come nico_ekito affermato in uno dei commenti, a mio la tua opinione, stai cadendo in questo "incubo della gestione delle dipendenze". Secondo il tuo scenario ... non è il fatto di gestire versioni diverse per i sottomoduli (oltre a una stabilità di codice diversa) un sintomo di quello che quei sottomoduli non fanno più parte del grande progetto?

Voglio dire, noi, come esseri umani, può affermare chiaramente che quei moduli fanno parte del quadro generale, l'intero meccanismo per risolvere un problema. Questo è abbastanza comune quando scopri che le tue classi di utilità non hanno alcun impiego al di fuori dell'ambito di quella grande immagine. Ma, dal punto di vista di Maven, penso che tu stia effettivamente affrontando diversi progetti piuttosto che moduli di uno grande.

Quindi, forse vale la pena di separare le basi di codice in diverse strutture e basta semplicemente fare riferimento ai vasi di utilità dai moduli che effettivamente lo richiedono e utilizzare solo build stabili invece di "ultima versione di tale dipendenza". Se si lavora con build stabili non è fattibile perché, anche se il codice per queste dipendenze è abbastanza stabile, continua a cambiare nello stesso momento del codice dagli altri moduli, quindi la soluzione che Maven ti dà sta usando SNAPSHOTS.

penso troverete alcuni vantaggi quando si rompe la base di codice in progetti distinti:

• In questo modo Maven non si innescherà un accumulo di tali moduli di utilità quando non è necessario.
• Se riesce a trovare un modo di solo usando rilasci stabili per le dipendenze si eviterà un sacco di problemi.
• Si può anche rompere la squadra e fare quelli di lavorare con solo i barattoli di utilità farlo su una "base sotto-demand" da parte del team che consuma che le dipendenze.
• Se queste utility sono astratti o abbastanza riutilizzabile si può trovare un giorno un altro progetto che può consumare anche loro, senza la necessità di fare riferimento a un modulo da un progetto più ampio.

C'è molta discussione in Internet sul modo in cui Maven handles dependencies (e altre cose) e molte persone si lamentano degli stessi problemi che si stanno affrontando. Secondo me, Maven è un ottimo strumento, progettato per farci risparmiare un sacco di tempo quando si iniziano nuovi progetti, ma a volte può essere un po 'macchinoso. Ho iniziato a dare un'occhiata ad altri strumenti come Gradle ma ora cambiare lo strumento di costruzione potrebbe essere la cosa peggiore da fare. Semplicemente dando un pensiero all'idea di rompere il codice base, a volte possiamo risolvere un "problema software" solo con un po 'di "project management" (o "portfolio mangement" in questo caso).