maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Hristov <nhris...@tidemark.com>
Subject Re: Proper way of inheriting versions on multi-module projects
Date Wed, 01 Apr 2015 16:34:18 GMT
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 <khmarbaise@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message