Jenkins maven deploy jar to nexus - artifact namin

问题:

My java/maven project called "testproject" is hooked up with my jenkins and nexus repo:

My pom.xml looks like:

....    
<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 set up, I have:

Build - maven3 - clean deploy

As expected, jenkins uploads the artifact to Nexus.Look at the console output from jenkins build, as 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 are:

Given the version I specified in pom.xml is

<version>0.1-SNAPSHOT</version>

1. How come jenkins upload testproject-0.1-20120509.161644-74.jar to Nexus? where is 20120509.161644-74 stuff coming from?

2. if the timestamp 20120509.161644-74 is generated by jenkins prior to uploading, can I configure the format of it? I want to have something like testproject-01-${timestamp}-${reversionId}.jar

回答1:

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

I don't know if what you want in 2) is possible. I think it might cause some trouble for maven.

When you use maven with SNAPSHOT dependencies, the timestamps are used to check for the most recent version of a SNAPSHOT. Changing the format of the snapshots would probably cause this mechanism to fail.

回答2:

The timestamp is added within a SNAPSHOT version since Maven 3. The same deploy plugin when executed with Maven 2 does not add any timestamp.

回答3:

That's Maven's way of locking down a version of a snapshot so a specific version can be consumed by another build - it kind of solves the problem, however it has shortcomings.

I've gone around the houses with snapshots. I believe they are simply evil. Build repeatability is a headache as it's tedious to correlate a timestamped snapshot version deployed to the repository with a particular code submission.

Save yourselves serious hassle and get your build server to call mvn versions:set -DnewVersion=..${build.number} on you build server prior to building/deploying. Tag your source code with the same version. If the build fails, it doesn't matter, the build can be configured to refresh the workspace rendering the pom.xml file changes irrelevant.

Another typical Maven "gotcha" in using snapshots is that you're not sure precisely which versions of dependencies your pom could be consuming during the build, so make sure your build calls dependency:tree and dependency:list, preceding your other mvn build arguments. (This will help you identify version inconsistencies of the same artifact during transitive resolution - I swear by the DependencyManagement section in my builds now).

While Maven goes a very long way, the "Maven Way" isn't always the best solution. It's not quite mature enough for Continuous Delivery best-practices, but you can still work with it effectively, providing you're aware of the pitfalls.