Jenkins Maven distribuire vaso per Nexus - artefatto denominazione

Question

Il mio progetto java/Maven chiamato "TestProject" è collegato con i miei Jenkins e Nexus repo:

mio pom.xml assomiglia:

....  
<distributionManagement> 
    <!-- use the following if you're not using a snapshot version. --> 
    <repository> 
     <id>nexus</id> 
     <name>RepositoryProxy</name> 
     <url>http://nexus:8080/nexus/content/repositories/releases</url> 
    </repository> 
    <!-- use the following if you ARE using a snapshot version. --> 
    <snapshotRepository> 
     <id>nexus</id> 
     <name>RepositoryProxy</name> 
     <url>http://nexus:8080/nexus/content/repositories/snapshots</url> 
    </snapshotRepository> 
</distributionManagement> 
...... 

In i miei Jenkins istituito, ho:

Build - maven3 - clean deploy 

come previsto, Jenkins carica il manufatto al Nexus.Look all'uscita console da Jenkins costruire, come di seguito:

[INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ testproject --- 
[INFO] Building jar: /var/lib/jenkins/workspace/testproject/target/testproject-0.1-SNAPSHOT.jar 
[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ testproject --- 
[INFO] Installing /var/lib/jenkins/workspace/testproject/target/testproject-0.1-SNAPSHOT.jar to /var/lib/jenkins/.m2/repository/com/dummy/testproject/0.1-SNAPSHOT/testproject-0.1- SNAPSHOT.jar 
[INFO] Installing /var/lib/jenkins/workspace/testproject/pom.xml to /var/lib/jenkins/.m2/repository/com/dummy/testproject/0.1-SNAPSHOT/testproject-0.1-SNAPSHOT.pom 
[INFO] 
[INFO] --- maven-deploy-plugin:2.5:deploy (default-deploy) @ testproject --- 
Downloading: http://nexus:8080/nexus/content/repositories/snapshots/com/dummy/testproject/0.1-SNAPSHOT/maven-metadata.xml 
Downloaded: http://nexus:8080/nexus/content/repositories/snapshots/com/dummy/testproject/0.1-SNAPSHOT/maven-metadata.xml (1012 B at 28.2 KB/sec) 
Uploading: http://nexus:8080/nexus/content/repositories/snapshots/com/dummy/testproject/0.1-SNAPSHOT/testproject-0.1-20120509.161644-74.jar 
Uploaded: http://nexus:8080/nexus/content/repositories/snapshots/com/dummy/testproject/0.1-SNAPSHOT/testproject-0.1-20120509.161644-74.jar (47 KB at 748.5 KB/sec) 
Uploading: http://nexus:8080/nexus/content/repositories/snapshots/com/dummy/testproject/0.1-SNAPSHOT/testproject-0.1-20120509.161644-74.pom 
Uploaded: http://nexus:8080/nexus/content/repositories/snapshots/com/dummy/testproject/0.1-SNAPSHOT/testproject-0.1-20120509.161644-74.pom (6 KB at 149.3 KB/sec) 

domande sono:

Data la versione che ho specificato in pom.xml è

<version>0.1-SNAPSHOT</version> 

1. Come mai Jenkins caricare testproject- 0.1-20120509.161644-74 .jar Nexus? dov'è la roba da 20120509.161644-74?

2. se il timestamp 20120509.161644-74 viene generato da jenkins prima del caricamento, posso configurare il formato di esso? Voglio avere qualcosa di simile TestProject-01 - $ {timestamp} - $ {} reversionId .jar

Answer 1

Il maven deploy plugin page dice che "Per impostazione predefinita, quando una versione un'istantanea di un artefatto viene distribuito a un repository, un timestamp è suffisso ad esso ". Quindi, viene creato dal plug-in quando si chiama mvn deploy.

Non so se quello che vuoi in 2) è possibile. Penso che potrebbe causare qualche problema a Maven.

Quando si utilizzano Maven con dipendenze SNAPSHOT, i timestamp vengono utilizzati per verificare la versione più recente di uno SNAPSHOT. La modifica del formato delle istantanee causerebbe probabilmente il fallimento di questo meccanismo.

Answer 2

Il timestamp viene aggiunto all'interno di una versione SNAPSHOT da Maven 3. Lo stesso plug-in di distribuzione eseguito con Maven 2 non aggiunge alcun timestamp.

Answer 3

Questo è il modo in cui Maven blocca una versione di un'istantanea in modo che una versione specifica possa essere utilizzata da un'altra build: risolve il problema, tuttavia presenta delle imperfezioni.

Ho girato le case con delle istantanee. Credo che siano semplicemente cattivi. Costruire la ripetibilità è un mal di testa poiché è noioso correlare una versione di snapshot timestamp distribuita nel repository con una particolare sottomissione di codice.

Risparmiate seri problemi e fate in modo che il vostro server di build chiami le versioni di mvn: set -DnewVersion = .. $ {build.number} sul server di build prima della creazione/distribuzione. Tagga il tuo codice sorgente con la stessa versione. Se la compilazione fallisce, non importa, la build può essere configurata per aggiornare l'area di lavoro, rendendo il file pom.xml non rilevante.

Un altro tipico "raggiro" di Maven nell'utilizzo di istantanee è che non si è sicuri con precisione quali versioni delle dipendenze potrebbero consumare durante la generazione, quindi assicurati che la dipendenza delle build dipenda: albero e dipendenza: elenco, precedente il tuo altri argomenti di generazione di mvn. (Questo ti aiuterà a identificare le inconsistenze della versione dello stesso artefatto durante la risoluzione transitiva - Lo giuro sulla sezione DependencyManagement nelle mie build ora).

Mentre Maven va molto lontano, la "Via dei Maven" non è sempre la soluzione migliore. Non è piuttosto abbastanza maturo per le best practice di Continuous Delivery, ma puoi ancora lavorarci efficacemente, a patto di essere consapevole delle insidie.