6

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?

Dave Hillier
  • 18,105
  • 9
  • 43
  • 87
beaker
  • 165
  • 1
  • 7
  • 2
    possible duplicate of [How to continuously build and deploy feature branches with Maven?](http://stackoverflow.com/questions/11413624/how-to-continuously-build-and-deploy-feature-branches-with-maven) – Mark O'Connor Dec 14 '13 at 11:13

1 Answers1

5

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.

Manfred Moser
  • 29,539
  • 13
  • 92
  • 123
  • I've defined two different job types in Jenkins. One for the continuous builds (listening on the feature/* branches) and one for the nightly builds (listening solely on the develop branch). In general the continuous build job doesn't deploy the artifacts produced on the feature branch; just the develop branch gets deployed. But in some cases you need to deploy SNAPSHOTS on the feature branch. Adapting the version number turned out to be working but it was no convincing solution for me. But obviously there's no better solution. What do you mean by "use the Versions Maven plugin"? – beaker Dec 19 '13 at 09:28
  • 1
    The Versions Maven Plugin can be used in a script to set the version to something different across the whole multi module project in one command. You can automate the version number change to include a branch name with it easily. – Manfred Moser Dec 19 '13 at 17:52