2012-06-07 10 views
5

Ho un genitore aziendale a livello aziendale con una sezione <dependencyManagement> che definisce le versioni dei miei progetti che dovrebbero essere utilizzate nella mia applicazione, alcune delle quali sono SNAPSHOTs, un po 'come questo:Maven Release Plugin non aggiorna gli SNAPSHOT in dependencyManagement

<dependencyManagement> 
    <dependencies> 
    ... 
    <dependency> 
     <groupId>my.group</groupId> 
     <artifactId>myArtifact</artifactId> 
     <version>1.0-SNAPSHOT</version> 
    </dependency> 
    ... 
    <dependencies> 
</dependencyManagement> 

Quando eseguo release:prepare sul pom principale, questi SNAPSHOT non vengono rimossi. Il risultato è che i progetti che ereditano dal genitore non possono usare le sue versioni quando vengono rilasciati. Come posso assicurarmi che la sezione <dependencyManagement> del genitore principale venga aggiornata quando rilascio?

Ho visto questa domanda: why does maven release plugin allow for SNAPSHOT version in dependency managment?, ma i biglietti citati reclamano di essere corretti nelle versioni precedenti del plug-in.

Maven Release Plugin 2.3.1 
Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+0000) 
Java version: 1.6.0_31, vendor: Sun Microsystems Inc. 
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" 
+0

È la parte di dipendenza fornita del tuo reattore? – khmarbaise

+0

No, in questo caso non lo è. Il padre genitore non ha alcun modulo dichiarato in esso, in quanto è utilizzato in una serie di diversi progetti. L'idea è di centralizzare cose che sono comuni a tutti i nostri progetti, come repository, metadati, ecc. Questo fa la differenza? – Conan

+0

Allora, qual è il tuo vero problema? - Non è possibile rilasciare il proprio progetto? - Vorresti lo snapshot della striscia plugin come viene menzionato in JIRA? –

risposta

1

Il maven-release-plugin riguarda solo la verifica della presenza di SNAPSHOT-s nella sezione <dependencies/>. Il <dependencies/> sarà ereditato da tutti i moduli che estendono questo genitore. Cercheranno sempre di risolvere queste dipendenze prima di costruire.

La differenza tra le sezioni <dependencies/> e <dependencyManagement/> è che quest'ultimo definisce solo le versioni che verranno utilizzate. Detto questo, il plugin di rilascio non è affatto interessato se è stato definito SNAPSHOT -s lì, a meno che questo progetto principale non sia un aggregatore o parte di un aggregatore e questo genitore venga rilasciato nel suo insieme con l'aggregatore.

Analogamente, il plug-in maven-release non si occupa di <pluginManagement/>. Inoltre, credo che indirizzi solo le proprietà Maven contenenti versioni di artefatto solo quando queste sono relative a <dependencies/>.

La parte peggiore è che, per quanto ricordo, non si verrà nemmeno avvisati se una dipendenza/plugin ha una versione SNAPSHOT, se si trova in una sezione <*Management/>.

Per questo motivo, l'approccio a cui ho fatto ricorso è di avere un POM padre con <properties/> contenente le versioni delle risorse utente. Prima di rilasciarlo, eseguo la scansione per SNAPSHOT -s utilizzando grep:

grep SNAPSHOT pom.xml 
+0

In realtà ho le versioni definite in '' nel padre pom, che sono quindi referenziate nella sezione ''. Speravo di definire tutte le versioni dei nostri progetti interni in un singolo pom come SNAPSHOT e di tenere tutte le versioni fuori dai nostri vari poms di progetto. Ciò si basa sul padre pom che specifica le versioni di rilascio in dependencyManagement, quindi suppongo che questo non funzionerà. Immagino che dovrò spostare le informazioni sulla versione in ogni progetto diverso, il che è un peccato. Voglio evitare di dover modificare manualmente le versioni come parte del processo di rilascio. – Conan

+1

Ciò che mi sorprende di questo è che quando rilascio un particolare progetto che eredita le versioni dalla sezione '' del genitore, che non si lamenta degli SNAPSHOT. Sembra che se le versioni non vengono menzionate nei poms che vengono rilasciati, il plugin di rilascio li lascia andare piuttosto che chiedere di rimuovere gli SNAPSHOT. – Conan

+1

Sono triste che '' si comporta in questo modo, ma sembra essere di progettazione, quindi accetto questa risposta. Grazie per il tuo feedback! – Conan

1

Così si sta cercando di liberare gli artefatti che non fanno parte della generazione che si sta preparando? Se fai un relase: esegui, quali artefatti dovrebbero caricare il plugin nel repository se non esistono? (se lo fanno, perché inserisci la versione dello snapshot?).
Penso che come detto @khmarbaise, il plugin non rimuoverà SNAPSHOTS che non fanno parte del tuo reattore (il plugin potrebbe pensare che siano dipendenze di terze parti).

Questo è un commento, l'ho messo come risposta perché non ho la reputazione di postare ancora commenti ... e Scusate il mio inglese!

+0

Sì, in questo scenario sto rilasciando solo un artefatto genitore, con l'imballaggio 'pom'. L'unico artefatto che mi aspetto di caricare in questo momento è il padre genitore. Quando si tratta di rilasciare un particolare progetto contenente codice, esso erediterà dal genitore rilasciato e quindi utilizzerà le versioni definite nella sua sezione ''; se contengono SNAPSHOT, allora il mio rilascio è in uno stato dubbioso in cui non posso fare affidamento sul fatto che possa essere riutilizzato in futuro. – Conan

+0

PS il tuo inglese è eccellente: D – Conan

+0

Come soluzione temporanea, se lo scopo della versione è solo sostituire SNAPSHOT su dependencyManagement e commit su SCM, dovresti provare a fare solo quel processo manualmente (o meglio fare un processo batch), non cambiare manualmente le versioni su ogni progetto, dai don donano! Prova qualcosa del genere (in un file .bat): sed -i/s-SNAPHOT // g 'pom.xml; cvs commette pom.xml. Puoi usare GnuWin per la funzionalità di sed, o meglio, iniziare a usare linux! –

Problemi correlati