Jenkins maven将jar部署到nexus - artifact命名

Question

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

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

Answer 2

自Maven 3以来，时间戳在SNAPSHOT版本中添加。使用Maven 2执行时，相同的部署插件不会添加任何时间戳。

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