Maven versions, subversion branches and local repository

Question

Imagine following scenario:

We have a lot of parallel development going on in several svn branches. Some projects are unbranched and some are branched. There is a lot of interdependency. We also have a local repository (so none of the developer downloads packages directly, we use our own maven repository).

The problem is with maven we have to specify versions in all the pom files. The artifacts with the version is stored in our local repository. While working with several branches, we will override same version (in the pom file) of artifacts with the artifacts from another branch.

If I use the version number in the pom file also to include some branch info, the problem arises for the unbranched modules which depend on many branched modules.

Is there any standard solution / policy to cope up with this issue ?

To create a separate repository for each branch is a solution, but looking at the number of branches we may have, it is a bit expensive.

Answer 1

I think your approach adding the branch name to the version is the correct one.

However you should try to avoid having unbranched artifacts depending on branched versions.

Consider you have A in trunk which depends on a version of B in a branch called DEV.

In this case I would argue that either A should depend on a released version of B in trunk or else should be in the DEV branch itself.

Hope that made sense...

Answer 2

I don't know of a standard approach to this. Generally it's easiest to differentiate branches by appending something different to the version number, or possibly the artifactID.

You can also use a numbering scheme to differentiate branches. For example if the trunk is version 2.0 (next major release), then the branch could be 1.1 (maintenance release for previous release).

I'm not sure what you mean by "our local repository". If you mean a shared internal team/company repository, then by all means you want to avoid version collisions across different branches, otherwise you will get very strange build problems with different artifacts having the same name/version.

If developers are working the branches ONLY on their local repositories and those branched artifacts are not getting added to some shared repository (via some CI server, for example) then you should generally be ok.

You also have to be careful about branched projects depending on shared artifacts.

Suppose you have A (trunk) and B (branch) both depending on C. If you make a change in C to support changes in B, then A will be affected. You have to branch B in this situation, or just be very careful.

Answer 3

Could you use the classifier feature for your artifact?

I don't think it's SOP to use classifier for this, but it should work. I believe the intent of classifier is to create different versions of an artifact based upon region specific filters, JDK versions, etc. But this seems to be a very project/environment specific thing so I think it would be just fine to hijack it for this.

If you were to specify your artifacts like this:

<artifactId>artifact-a</artifactId>
<groupId>com.mygroup</groupId>
<version>1.1-SNAPSHOT</version>
<classifier>BRANCH-Q</classifier>

In your repository you would get:

artifact-a-1.1-SNAPSHOT-BRANCH-Q.jar

Then you could specify artifacts in dependencies using the classifier to get the right one.