Re: Proper way of inheriting versions on multi-module projects

[Karl Heinz Marbaise <kh...@gmx.de>]

Hi,

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.


[1] http://maven.apache.org/maven-release/maven-release-plugin/
[2] http://mojo.codehaus.org/versions-maven-plugin/
[3] http://maven.apache.org/docs/3.2.1/release-notes.html


Kind regards
Karl Heinz Marbaise

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Proper way of inheriting versions on multi-module projects

[Nick Hristov <nh...@tidemark.com>]

Karl,

Thanks for the help.

The reason why I said that multiple versions in the pom.xml is a pain is
due to the fact that these copies have to be maintained. Tooling needs to
be done for them: you yourself mentioned that I have to use plugins to
solve the problem (versions plugin or release plugin). We use either
versions plugin or our own tools.

Particularly unpleasant is the fact that they cause conflicts when many
branches are created, each with their own separate version. I suppose we
could have avoided this by having our pom.xml files mutated after a
checkout during the build phase (and keep one version across all branches):
we chose not to do that.

I will try to utilize the properties that you mentioned in our build.

Nick

On Tue, Mar 31, 2015 at 11:46 PM, Karl Heinz Marbaise <kh...@gmx.de>
wrote:

> Hi,
>
> 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.
>
>
> [1] http://maven.apache.org/maven-release/maven-release-plugin/
> [2] http://mojo.codehaus.org/versions-maven-plugin/
> [3] http://maven.apache.org/docs/3.2.1/release-notes.html
>
>
> Kind regards
> Karl Heinz Marbaise
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>