Jenkins Maven wdrażać jar Nexus - artefakt nazewnictwa

Question

Mój projekt java/Maven zwany "testproject" jest podłączona z moich Jenkins i nexus repo:

Moje pom.xml wygląda następująco:

....  
<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> 
...... 

W moi Jenkins utworzone, mam:

Build - maven3 - clean deploy 

Zgodnie z oczekiwaniami, Jenkins przesyła artefakt do Nexus.Look na wyjściu z konsoli Jenkins budować, jak poniżej:

[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) 

Pytania są:

Biorąc pod uwagę, że wersja określona w pom.xml jest

<version>0.1-SNAPSHOT</version> 

1. Dlaczego Jenkins przesłać testproject- 0.1-20120509.161644-74 .jar do Ogniwo? skąd pochodzi 20120509.161644-74?

2. jeśli sygnatura czasowa 20120509.161644-74 jest generowana przez Jenkinsa przed przesłaniem, czy mogę skonfigurować jej format? Chcę mieć coś podobnego testproject-01 - $ {datownika} - $ {reversionId} .jar

Answer 1

maven deploy plugin page mówi, że „Domyślnie, gdy wersja snapshot artefakt został wdrożony do repozytorium, A znacznik czasu jest do niego dodany ". Tak więc jest tworzony przez wtyczkę, gdy wywołujesz mvn deploy.

Nie wiem, czy to, co chcesz w 2), jest możliwe. Myślę, że to może sprawić kłopot dla maven'a.

Gdy używasz maven z zależnościami SNAPSHOT, znaczniki czasu są używane do sprawdzania najnowszej wersji SNAPSHOT. Zmiana formatu migawek prawdopodobnie spowodowałaby awarię tego mechanizmu.

Answer 2

Znacznik czasu jest dodawany w wersji SNAPSHOT od wersji Maven 3. Ta sama wtyczka wdrażania po uruchomieniu z Maven 2 nie dodaje żadnego znacznika czasu.

Answer 3

To sposób, w jaki Maven blokuje wersję migawki, aby konkretna wersja mogła zostać wykorzystana przez inną kompilację - to rozwiązuje problem, ale ma pewne wady.

Przeglądałem domy z migawkami. Uważam, że są po prostu źli. Powtarzalność kompilacji to ból głowy, ponieważ jest to żmudne korelować z wdrożoną wersją migawki sygnaturę czasową do repozytorium z konkretnym przesłaniem kodu.

Oszczędzaj sobie poważnych kłopotów i niech twój serwer kompilacji zadzwoni do wersji mvn: set -DnewVersion = .. $ {build.number} na twoim serwerze kompilacji przed budowaniem/wdrażaniem. Dodaj swój kod źródłowy do tej samej wersji. Jeśli kompilacja się nie powiedzie, nie ma to znaczenia, kompilacja może zostać skonfigurowana do odświeżenia obszaru roboczego, co spowoduje, że zmiany pliku pom.xml będą nieistotne.

Innym typowym "przystawką" Mavena przy użyciu migawek jest to, że nie jesteś pewien dokładnie, jakie wersje zależności Twój pom może zużywać podczas kompilacji, więc upewnij się, że zależność budowania wywołań: drzewo i zależność: lista, poprzedzająca twoje inne argumenty budowania mvn. (To pomoże ci zidentyfikować niespójności wersji tego samego artefaktu podczas przechwytywania przechodniego - przysięgam teraz w sekcji DependencyManagement w moich kompilacjach).

Podczas gdy Maven idzie bardzo długą drogą, "Droga Maven" nie zawsze jest najlepszym rozwiązaniem. To nie jest wystarczająco dojrzałe, aby stosować najlepsze praktyki w zakresie dostarczania ciągłego, ale nadal można z nim pracować skutecznie, pod warunkiem, że jesteś świadomy pułapek.