Maven and SVN branches
Now, Maven doesn’t go too well with SVN branches out of the box. You “svn copy” and you start making changes in your new brunch, then you “mvn clean install” or even “mvn clean deploy” (although we only let Hudson to “mvn deploy”).
Stop.
What goes into your local repo and Artifactory ?
You’re overriding your trunk artifacts with those from the branch!
Whops.
If branch POMs are the same as those in a trunk – that’s exactly what’s going to happen: artifacts are overriding each other. Both in your local repository and your intranet repository manager as well (I’ve had this case for real – a nightly branch build was overriding all trunk’s artifacts in Artifactory). Of course, it can be solved by working with separate local and remote repos when dealing with branches but I think it requires too much attention and it’s still fragile – you forget to “-Dmaven.repo.local” when running Maven in branch and you’re back making a big mess in trunk’s local repo.
What I did in ClearForest was something else – I’ve modified all <groupId> of branch POMs with this simple Groovy script:
The main idea, as you see, is following: modify all <groupId> by appending a branch name, commit and you’re fine again – artifacts from different branches are located in different namespaces and can now seat safely side-by-side in local and remote repos, without overriding each other.
How do you solve this issue ?
Goldin, the Junior 
Any specific reason not to set the version containing the branch information and change the groupId instead ?
Indeed, we thought about changing all versions instead. But since we’re using SNAPSHOT for versions – I thought changing groupId would be more appropriate: all versions stay SNAPSHOT but all artifacts are now getting their own namespace. *If* we had a way to change a version in one place so that it’ll change versions in all POMs – then we could probably do it. But today – in order to change all versions in all our POMs (and we have maaaany of them, spread all over big SVN tree) I would need to use a similar script as well. So going on groupId was more natural for me – something had to be modified for all branched POMs anyway and I picked up groupId.
Thanks for the explanation. We are also facing the similar situation with svn and maven and to make the situation worse, we also have some unbranched modules depending on branched ones.
Wow, that’s scary. But in your case carefully using <version> should work Ok, I suppose.
Can anybody suggest me best approch to go about in case we have a existing SVN environment and need to integrate maven and crusie control to it.
Hi,
Do you have any specific issue ? Otherwise, your question is too general for me.
Wow, we have this exact same problem. This is exactly what I thought of doing, great stuff!
Hi Matt, glad you find it useful. Our Groovy script became much more involved then this initial version pasted in the post (we made it fix some other things as well, like \t => 4 spaces, the branch name is now calculated automatically from ‘svn info’) but the main idea remained the same. Some people say changing <version> is better so we might consider this as well.
I’ll be open-sourcing this script as a Maven plugin. When it’s done – I’ll post it in the blog.