Hierarchy of maven projects without scattering the version number

Question

If you use Maven2 as a build system for a project containing many artefacts with the same version number, you have the version of the resulting build scattered in all pom.xml. In many of them even twice - in the version tag of the artefact itself and in the version tag of the parent. Thus, you have to change and check in new versions of all pom.xml on every version switch. This is somewhat annoying, especially if you have to code for several bug fixing and a development version in parallel. Is there a way around that?

CLARIFICATION: My question is about the many versions of every single pom.xml that you get over time in your source control system that differ only by the version number of the pom and / or the version number of the parent pom. Ideally, you should only need to change the pom whenever you add a dependency or something.

For example you have a project with the artifacts foo-pom (the parent pom to all), foobar-jar, foobaz-jar and foo-war. In the first release the version is 1.0 - which appears in every pom.xml. In the second release the version is 1.1 - which again appears in every pom.xml. So you have to change every pom.xml - this is annoying if you release as often as you should.

UPDATE: If you think this is important: not having to specify the parent version is already being considered. Please go to the maven JIRA issue and vote for it to get it more noticed and more likely to be added as an enhancement in an upcoming release. You need to create/have a JIRA login for that.

There is another Stackoverflow Question that is basically about the same problem.

Answer 1

There's another StackOverflow thread that also covers this topic that you might want to look at.

In short, not having to specify the parent version when using inheritance is already being considered. Please go over to JIRA and give it a vote bump to get it more noticed and more likely to be added as an enhancement in an upcoming release.

Answer 2

I've run into similar problems while working on a large system built with Maven 2.

In my opinion, the downside of the typical multi-module structure is that all modules have to share the same version. This is indeed annoying: even if your next release only consists in a bugfix in foobar-jar, you need to change the global version everywhere (be it manually or with maven-release-plugin) and roll a new release of every component. In my case, I built various WAR/EAR applications, so my customer would ask me why I delivered a new version of both app1 and app2, when only app1 was supposed to be impacted.

The opposite approach is to manage each component as an independent project, with its own independent version. This is more flexible as it allows partial releases, but you now need to track all these versions manually (know which versions your next delivery will consist in, make sure internal dependencies are consistent, etc.). This can quickly become a nightmare in a large application.

I've long thought about a way to combine both approaches: the flexibility of independent versions, without giving up the global coherency of the system. I tried the same approach as romaintaz, and ran into the same problem. Finally, I came up with this idea: http://out-println.blogspot.com/2008/10/maven-modules-with-independent-versions.html.

Consider it as 'experimental', as I didn't get to try it live in the end (for non-technical reasons). But I think it would do the trick.