Jenkins maven deploy jar for nexus - artifact assignment

Question

My java / maven project called "testproject" connects to my jenkins and nexus repo:

My pom.xml looks like this:

.... <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 my jenkins settings, I have:

 Build - maven3 - clean deploy 

As expected, jenkins loads the artifact into Nexus.Look at the console output from the jenkins assembly, as shown below:

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

Questions :

Given the version specified in pom.xml,

 <version>0.1-SNAPSHOT</version> 

• How is it that jenkins loads testproject- 0.1-20120509.161644-74 .jar on Nexus? where is 20120509.161644-74 material coming from?

• if timestamp 20120509.161644-74 is generated by jenkins before downloading, can I customize its format? I want to have something like testproject-01 - $ {timestamp} - $ {reversionId} .jar

Answer 1

The maven deploy page reports that "By default, when a snapshot version of an artifact is deployed to the repository, the timestamp is a suffix to it." Thus, it is created by the plugin when you call mvn deploy .

I don't know if what you want is possible in 2). I think this may cause some problems for maven.

When you use maven with SNAPSHOT dependencies, timestamps are used to check the latest version of SNAPSHOT. Changing the image format is likely to cause this mechanism to fail.

Answer 2

The timestamp is added in the SNAPSHOT version from Maven 3. The same deployment plugin, when executed with Maven 2, does not add a timestamp.

Answer 3

This is Maven’s way to block the snapshot version, so a specific version can be used by another assembly - it solves the problem, but it has drawbacks.

I went around the house with pictures. I think they are just evil. Building repeatability is a headache because it is tedious to compare the temporary version of a snapshot deployed in the repository with a specific code feed.

Save yourself from serious problems and get the build server to invoke the mvn versions: set -DnewVersion = .. $ {build.number} on the build server before creating / deploying. Mark your source code with the same version. If the assembly failed, it does not matter, the assembly can be configured to update the rendering of the workspace, that the pom.xml file does not matter.

Another typical Maven catch when using snapshots is that you don’t know exactly which version of the dependencies your pom might consume during build, so make sure your dependency causes a dependency: tree and dependency: the list preceding your another mvn build arguments. (This will help you identify inconsistencies in versions of the same artifact during transitional resolution - I swear now in the DependencyManagement section in my builds).

While Maven takes a very long time, "Maven Way" is not always the best solution. It is not well developed for advanced continuous delivery methods, but you can still work effectively with it, providing you with information about the pitfalls.