maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Heinz Marbaise <>
Subject Re: Proper way of inheriting versions on multi-module projects
Date Wed, 01 Apr 2015 06:46:35 GMT

On 3/31/15 10:08 PM, Nick Hristov wrote:
> Hello,
> In my company we have a really large codebase, and it is structured in
> over 100 modules.
> All modules are released together: they have the same version.
> Historically, we have had the version embedded in every pom at least
> twice: once for the module itself, and once for the parent version
> reference.

I believe with a recent upgrade, the number of versions goes
> in half: child modules can inherit the version.

Usually you only need the version in the parent element only cause the 
version is inherited so you can omit the version within the module 
itself. And best practice is not to define a supplemental version in the 
child element.

> The problem is that we still must put the parent's version in every
> module. This leaves us with still over 100 repetitions of version string
> in the project.

> Obviously we have tools to automate the switching of versions, but this
> is still causing us pain.

In which way is it causing pain?

Why not using the existing tools of Maven. First 
[maven-release-plugin][1] will handle this. If you don't like to use 
maven-release-plugin you can use [versions-maven-plugin][2]....

> Will maven at any point support omitting the <version> from the <parent>
> xml element? If <relativePath> is specified, why does a version have to
> be present? Wouldn't specifying a version when a <relativePath> is
> present lead to two sources of information (i.e. child specifying
> version, yet pointing to a parent pom which may have conflicting version)?

The relative path in your examples it not neccessary cause it's the 
default which you have defined. So you can omit the relativePath from 
the parent elements.

The point here is. A parent can reference the parent within the reactor 
but does not need to so that's the reason why you have to give the 
version as well.

Omitting the version element from the parent could be done only with 
Maven 4.X but not in Maven 3 cause it would break all existing Maven 
versions and toolings.

> Furthermore, I was able to get to a solution to this problem, but it
> appears brittle. A sample project is attached.
> The attached sample project also breaks if the version is a constant in
> the parent pom.xml. (i.e. <version>1.0-SNAPSHOT</version>) Can't figure
> why that is. I am using the following maven version:
> mvn --version
> Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
> 2014-12-14T09:29:23-08:00)
> Maven home: /Development/vendor/apache-maven-3.2.5
> Java version: 1.7.0_71, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.10.2", arch: "x86_64", family: "mac"
> Thank you for your help,

Based on your used Maven version you can use the following which is part 
of maven since Maven 3.2.1:

You can define the version using the following [properties][3]:

A simple change to prevent Maven from emitting warnings about versions 
with property expressions. Allowed property expressions in versions 
include ${revision}, ${changelist}, and ${sha1}. These properties can be 
set externally, but eventually a mechanism will be created in Maven 
where these properties can be injected in a standard way. For example 
you may want to glean the current Git revision and inject that value 
into ${sha1}. This is by no means a complete solution for continuous 
delivery but is a step in the right direction.


Kind regards
Karl Heinz Marbaise

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message