Question

I have a difficult case to solve regarding the Maven automated projects versioning, I hope I’ll find a proper solution based on your experience and advices.

The problem is like that:
We have a huge mavenized java product which comprise of ~200 very interdependent different projects.
We agreed that each project should be developed independently, so that each of them should have it’s own lifecycle.
It’s all working fine in the development stage, there is no problem. The problem comes when we are preparing the release for these projects: Because the are so many projects the manual changes are a pain so we decided to find an automated solution to solve the release process.

The prequisites are these:
We all agreed that the release policy from SVN perspective should be like that:
– all development should be performed on SVN trunk, releases should be created and maintained on branches. Each performed release should automatically create a tag.

The policy from MAVEN perspective is like that:
– before releasing a project, we first copy the trunk to a branch in order to have control over projects maintainance on the branched code. The versioning system we choose is: Major.Minor.BuildNumber-SNAPSHOT (e.g. 1.0.0-SNAPSHOT). When branching the code, we want to change the project version number by incrementing the MinorVersion (e.g trunk-1.0.0-SNAPSHOT will become 1.1.0-SNAPSHOT, and 1.0.0-SNAPSHOT will be copied and released on the new created branch)
– when we decide that the project is mature enough in order to be released we are releasing it by using maven-release-plugin (mvn release:clean release:prepare release:perform) so that our project version will be transformed from Major.Minor.BuildVersion-SNAPSHOT (e.g. 1.0.0-SNAPSHOT) to Major.Minor.BuildVersion (e.g. 1.0.0), then will be prepared for the next development iteration like: Major.Minor.BuildVersion+1-SNAPSHOT (e.g. 1.0.1-SNAPSHOT)

The problems we are facing are related to projects versioning.
So, during the development phase on the trunk, all the projects are using the latest SNAPSHOT versions of their dependencies (mvn versions:use-latest-versions -DallowSnapshots=true -DupdateDependencies=true), but when we consider it’s time to start the release procedure and prepare to branch the code, there problems start:
we are start branching

1. parent-pom

   (mvn -B release:clean release:branch -DbranchName=${project.artifactId}_${project.version} -Dusername=${username} -Dpassword=${passwd} -Dproject.rel.${groupId}:${projectId}=1.0.0-SNAPSHOT
   -Dproject.dev.${groupId}:${projectId}=1.1.0-SNAPSHOT)

   • copy project from trunk to new created branch, transform pom version on trunk from 1.0.0-SNAPSHOT to 1.1.0-SNAPSHOT

2. non-dependent projects

   (mvn -B release:clean release:branch -DbranchName=${project.artifactId}_${project.version} -Dusername=${username} -Dpassword=${passwd} -Dproject.rel.${groupId}:${projectId}=1.0.0-SNAPSHOT
   -Dproject.dev.${groupId}:${projectId}=1.1.0-SNAPSHOT versions:update-parent
   -DallowSnapshots=true)

   • copy project from trunk to new created branch,
   • transform the trunk pom version 1.0.0-SNAPSHOT become 1.0.1-SNAPSHOT
   • update parent-pom.version: 1.0.0-SNAPSHOT become 1.1.0-SNAPSHOT

3. dependent projects:

   (mvn -B release:clean release:branch -DbranchName=${project.artifactId}_${project.version} -Dusername=${username} -Dpassword=${passwd} -Dproject.rel.${groupId}:${projectId}=1.0.0-SNAPSHOT
   -Dproject.dev.${groupId}:${projectId}=1.1.0-SNAPSHOT versions:update-parent
   -DallowSnapshots=true versions:use-latest-versions -DallowSnapshots=true
   -DupdateDependencies=true)

   • copy project from trunk to new created branch
   • transform pom version on trunk from 1.0.0-SNAPSHOT to 1.1.0-SNAPSHOT
   • update parent-pom on trunk from 1.0.0-SNAPSHOT to 1.1.0-SNAPSHOT
   • update the already branched dependency projects from 1.0.0-SNAPSHOT to 1.1.0-SNAPSHOT

The first problem here is that there is no way yet to have an argument to increase the MinorVersion when branch the project, the maven-release-plugin 2.2.2 does not increment the pom MinorVersion on trunk when branching, so that’s why we need to use -Dproject.rel.${groupId}:${projectId}=1.0.0-SNAPSHOT
-Dproject.dev.${groupId}:${projectId}=1.1.0-SNAPSHOT arguments and change them manually for every project, so 200 times every time when we preapare for a new release.

I’m wondering if it’s not a way to make all described procedure somehow in an automated fashion and to not need to perform all these changes manually all the time.
We’ve taking account even to modularize this product so that to colapse those 200 project in 100 probably, but this is not acceptable since the idea is to have a fine grained projects versioning and have all the projects with it’s own lifecycle, so an aggregator (I mean a classic one) is out of discussion here.

We are using SVN as VCS, Maven as build tool (probably you already figured out about that 🙂 ), and Bamboo as a CI server (actually, instead of “Maven Dependency Processor” feature, Bamboo is not helping me to much regarding the versioning problem).

Do you guys have any idea in order to find a proper solution for this problem, maybe another plugin which would help (versions-maven-plugin does not change versions automatically when branch), maybe another point of view for this, I don’t know…, any help or sugestion are welcome.

Thanks!

Answer 1

I try to avoid keeping internal projects versions in the <properties> section of the parent-pom, since every time when I release a project, the <version>${project.version}</version> variable will be switched with the explicit version of the project like:

<properties>
        <project_A.version>1.0.0-SNAPSHOT</projectA.version>
</properties>

stored in parent pom, translated in the projects pom like: ${project.version}, will become 1.0.1-SNAPSHOT when release that project, and will overwrite the <project_A.version> version from parent-pom <properties>. So this trick of keeping the projects versions as properties in a centralized location like the parent-pom, is valid as long as you don’t release the projects.
This is the question strictly related to the branching question.

---

---

Now, if you want I can tell you more about releasing the projects using this <properties> substitution:
Lets’s say you want to release your project_A, what will you do with the <projectA.version> stored in the parent pom <properties> which is a -SNAPSHOT version when you start to release the parent pom, right? I mean, in order to release a project, you’ll release all its dependencies and its related parent-pom first right? otherwise your project release will fail since is pointing to a -SNAPSHOT version of the parent pom.
Now, you are releasing the parent-pom keeping the -SNAPSHOT version of project_A inside of it’s <properties>, next when you’ll release the project_A, your project will refer to the new created release version of your parent pom, which parent pom released version is refering to the -SNAPSHOT version of your project_A, still not a problem since your parent pom is keeping the true version of your project_A, until your projectA released version (lets say 1.0.0) will refer to the same parent pom released version which is containing 1.0.0-SNAPSHOT version of your project_A, and now you have a problem already because your parent pom <properties> is keeping a wrong info.
Ofcourse you can hack the parent pom when release it and store the release version of project_A, but this against the rules and I would not agree with that at all, plus that are other scenarios when this “hack” will cause more problems than help.

I’m sorry if this sounds pretty complicated and detailed but I just want to explain as much as possible the real life situation not just theoretical, plus that I also need to keep in mind that I have 200+ projects I need to keep somehow aligned.