Maven tips and tricks

git-branch-renamer-maven-plugin

When working with many feature/release/bugfix/hotfix branches, it is a bad idea to start changing the pom version as this will create merge conflicts using pull request. this plugin allows you to keep in ALL branches the same pom version for all your projects, for example MASTER-SNAPSHOT the version will be derived from branch name automagically 🙂

git-branch-renamer-maven-plugin allow you to keep in ALL branches the same pom version for all your projects: for example MASTER-SNAPSHOT and never change it again.

the project version will be derived from branch name automatically when running in your continuous integration server.

branch name feature/xxxx

• <version>xxxx-SNAPSHOT</version> (default)
• <version>xxxx</version> (release = true)
• <version>0-xxxx-SNAPSHOT</version> (forceNumericalVersion = true)
• <version>feature-xxxx-SNAPSHOT</version> (filterOutBranchQualifier = false)

The project is hosted at GitHub https://github.com/cedricwalter/git-branch-renamer-maven-plugin

Fetching artifact programmatically through REST/API in Nexus 3.x

There is so many case where it is desirable to pull down artifact from Sonatype #Nexus using REST API, unfortunately #Nexus 3.x Rest API are still under development…

Some use cases in Nexus 2.x:

• You have a script that uses #REST call to pull down the LATEST maven artifacts every night from Nexus and deploys them.
• You make extensive use of the #REST API in all your puppet modules
• You use the #Atlassian #Puppet module for Nexus for creating repository, groups, assigning repository to groups, updating the main config settings, things like proxy, email, realms, and so on. The Puppet module is simply a wrapper over the Nexus REST API and allows to essentially import those abstractions into #Puppet Config Management

Here is one possible workaround that does not use any REST API

mvn org.apache.maven.plugins:maven-dependency-plugin:3.0.1:copy
    -Dartifact=log4j:log4j:1.2.17:jar
    -DoutputDirectory=./

which is equivalent to Gist Link

war plugin vs assembly plugin

When in #apache #maven you have multiple dependencies with the same artifact id but different group id

<dependencies>
    <dependency>
        <artifactId>any</artifactId>
        <groupId>groupId1</groupId>
        <version>1.1</version>
    </dependency>
    <dependency>
        <artifactId>any</artifactId>
        <groupId>groupId2</groupId>
        <version>1.2</version>
    </dependency>
    <dependency>
        <artifactId>any</artifactId>
        <groupId>groupId3</groupId>
        <version>1.3</version>
    </dependency>
</dependencies>

So it’ll look like this in WEB-INF/lib

-rw------- 1 user grp  135851 Aug 24 12:21 grp1-any-1.1.jar
-rw------- 1 user grp 1406696 Sep 18 11:51 grp2-any-1.2.jar
-rw------- 1 user grp   88873 Aug 19 13:58 grp3-any-1.3.jar

Apache maven war plugin is able to detect this case and will automatically add the groupId to resolve filename conflicts. If it would not do that the last one name any.jar would win

In maven Assembly this will not occur, and the last file name will be the only one available. There is at least two way to solve this issue:

1. Use unique groupid and artifactid name: something you can do across your module code, it can be done if these dependencies are real 3rd party librairies
2. Use the outputFileNameMapping in assembly

<outputFileNameMapping>${artifact.groupId}-${artifact.artifactId}-${artifact.baseVersion}${dashClassifier?}.${artifact.extension}</outputFileNameMapping> 

${artifact.artifactId}-${artifact.baseVersion}.${artifact.extension}

Another use case for outputFileNameMapping is when you want to remove the timestamp from filename but keep the version in assembly dependencySet