CODEWITHSUNDEEP
mavenjenkinsmaven-3pom.xmlnexus
OrionRogue
OrionRogue

Reputation: 398

How to programmatically use older snapshot artifacts stored in Nexus

In our build and deploy infrastructure, we have a Jenkins job that builds our multi-module Maven projects, and recently has been deploying the resulting artifacts (including an omnibus tarball) to Nexus. Then another job (sometimes triggered by a successful build job) runs the deploy, which pulls the required artifact from Nexus, based on the POM that the build job ran (the build job archives the POM so that the tarball can be retrieved by using the dependency:copy goal). For releases, this works fine and we can even deploy an earlier version if a rollback scenario is required. However, this breaks down for SNAPSHOT builds, because the POM does not contain any version identifier beyond that the artifact is a -SNAPSHOT.

The build output does contain information that could be grepped after the build is complete, so that we could use that as the version. Those familiar with Maven will recognize the following Maven output snippet:

[INFO] Uploading: http://nexus.eng.company.com/nexus/content/repositories/snapshots/com/company/application/application-dist/4.19.3-SNAPSHOT/application-dist-4.19.3-20160819.223606-7-eng.tar.gz

[INFO] Uploaded: http://nexus.eng.company.com/nexus/content/repositories/snapshots/com/company/application/application-dist/4.19.3-SNAPSHOT/application-dist-4.19.3-20160819.223606-7-eng.tar.gz (109687 KB at 413.1 KB/sec)

But is there a better way? The situation we are specifically trying to allow is for developers to deploy earlier builds (usually to deploy feature branch builds) but that currently isn't possible unless I find a way to grab that datestamped version identifier.

Upvotes: 2

Views: 541

Answers (1)

A_Di-Matteo
A_Di-Matteo

Reputation: 27812

A possible solution would be to create a dynamic property to use a classifier. The build-helper-maven-plugin can help in this case, e.g. with the following:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>build-helper-maven-plugin</artifactId>
    <version>1.10</version>
    <executions>
        <execution>
            <id>regex-property</id>
            <goals>
                <goal>timestamp-property</goal>
            </goals>
            <configuration>
                <name>custom.classifier</name>
                <pattern>yyyy-MM-dd_HH-mm-ss.SSS</pattern>
            </configuration>
        </execution>
    </executions>
</plugin>
<plugin>
    <artifactId>maven-jar-plugin</artifactId>
    <version>3.0.2</version>
    <configuration>
        <classifier>${custom.classifier}</classifier>
    </configuration>
</plugin>

Above we are creating a new property, custom.classifier, and filling it with a timestamp defined by the pattern element (crafted so that no spaces nor invalid characters would be part of it, since classifier will be part of the final file name).

Then the maven-jar-plugin case set the classifier accordingly.

You could then further wrap the behavior above in a Maven profile in order to activate it only for CI jobs.

Upvotes: 2

Related Questions