Feature-based development with Sonatype Nexus OSS

Question

I'm wondering if it's possible to work on a maven project on several feature branches simultaneously and avoid constantly overwriting the artifacts produced by other feature branches in Nexus.

I'm working in a multinational project which uses the gitflow workflow for developing several components (30+). There's a git repository for each component and therefore the gitflow workflow is applied to each component. So each component has a develop and several feature branches. In general each component produced at least one artefact identified by its GAV.

Let's say we have the components A (with the feature branches feature/A-foo and feature/A-bar) and B (with the feature branch feature/B-foo)

Component A:
A:develop
A:feature/A-foo
A:feature/A-bar

Component B:
B:develop
B:feature/B-foo

A:feature/A-foo and B:feature/B-foo work on the same topic and need to exchange snapshot versions in order to test their interaction (e.g. client/server feature). Component A and B can only exchange artifacts via Nexus (sourcecode of other component is not accessible). So A:feature/A-foo must deploy its snapshot artifacts to make it available for B:feature/B-foo and vice versa.

BUT when A:feature/A-bar (which works on a completely different topic) deploys afterwards, it "overwrites" the snapshot artifacts in Nexus due to the same GAV and more recent timestamp and B:feature/B-foo will import the wrong artifacts in its next build.

One solution is to extend the GAV with the feature name (e.g. foo):

some.company.componentA-1.2.3-foo.jar
some.company.componentA-1.2.3-bar.jar
some.company.componentB-3.2.1-foo.jar

This way you can avoid that A:feature/A-foo is overwriting the artifacts of A:feature/B-bar because they have different GAVs. But this is very error-prone (renaming of GAV when branching off and renaming it back when merging onto develop again; if someone forgets to rename it, it will mess up the build).

Is there any better solution? Or should it be forbidden to deploy on a feature branch?

Answer 1

Feature branches should not be long lived and therefore in many cases you end up not deploying at all. However if you do want to deploy (and thats a good thing) the branch qualifier in the version string is the best approach. If you automate branch creation with a script that takes care of the version changes it is not that error prone at all and actually a good sanity of your overall strategy. Add in a feature specific CI job (or a few of them) and maybe use the Versions Maven plugin and you should be ready to roll.