Maven 2 & 3

Version ranges not supported for parent artifacts

Details

  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

It would be great if Maven supports version ranges when specifying parent artifacts in a multi-module build. Currently this does not work.

<parent>
<artifactId>artifactId</artifactId>
<groupId>groupId</groupId>
<version>[2.0, 2.0.1]</version>
</parent>

[INFO] Scanning for projects...
Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 2.0.1]/artifactId-[2.0, 2.0.1].pom

Additionally it would be great if this

<parent>
<artifactId>artifactId</artifactId>
<groupId>groupId</groupId>
<version>[2.0, ${pom.version}]</version>
</parent>

[INFO] Scanning for projects...
Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, ${pom.version}]
/artifactId-[2.0, ${pom.version}].pom

would also work, if the version is specified in the same pom.xml which defines this parent definition.

Issue Links

Activity

Hide
Kenney Westerhof added a comment -

tempting to 'close - won't fix'.

Whatever parent pom is present in the local repo will be used, resulting in a different effective pom on different systems.
This'll be the cause of all sorts of problems.

Show
Kenney Westerhof added a comment - tempting to 'close - won't fix'. Whatever parent pom is present in the local repo will be used, resulting in a different effective pom on different systems. This'll be the cause of all sorts of problems.
Hide
Sander Nieuwenhuizen added a comment -

It makes no sense imho that you cannot set a version range for the parent as you can with any other (regular) dependency. I would like the option to let my artifact lift on the latest version of the parent instead of linking it strictly to a specific version of the parent.

Show
Sander Nieuwenhuizen added a comment - It makes no sense imho that you cannot set a version range for the parent as you can with any other (regular) dependency. I would like the option to let my artifact lift on the latest version of the parent instead of linking it strictly to a specific version of the parent.
Hide
Sylvain Marié added a comment -

+1

The parent should be handled exactly the same way than other dependencies. Increasing manually all children's poms everytime a new reporting option has been set in the parent is not very handy. Same for release configuration, license handling , etc... in all these cases I would like the children projects to just take the latest version of the parent, or range [X.X.0,X.X+1.0) for example.

Show
Sylvain Marié added a comment - +1 The parent should be handled exactly the same way than other dependencies. Increasing manually all children's poms everytime a new reporting option has been set in the parent is not very handy. Same for release configuration, license handling , etc... in all these cases I would like the children projects to just take the latest version of the parent, or range [X.X.0,X.X+1.0) for example.
Hide
Todor Boev added a comment -

I think there is an acceptable alternative: Make <relativePath> pick up the maven coordinates of the parent pom automatically.

Most multi-module builds form a monolithic tree of poms that is always checked out atomically. I.e. we have a specific tree layout in the file system that has <module> for forwards links and <parent> for backlinks. If <module> does not need full maven coordinates why should parent? Imagine we can use either maven coordinates or a single <relativePath> as parent:

<parent>
<relativePath>../pom.xml</relativePath>
</parent>

Than the entire multi-module project can have a single groupId and version set in the root pom. We would be able to control the common version of this logical set of artifacts from one file - no more need to edit dozens of <parent> clauses for every trivial change. All that is needed is for Maven to replace <relativePath> with the actual maven coordinates when we install/deploy.

For that matter why don't we make <module> accept a set of maven coordinates as well? Than both the forward and backward links would support two modes: maven coordinates and the repo or local file system and automatic maven coordinate interpolation upon install/deploy.

Show
Todor Boev added a comment - I think there is an acceptable alternative: Make <relativePath> pick up the maven coordinates of the parent pom automatically. Most multi-module builds form a monolithic tree of poms that is always checked out atomically. I.e. we have a specific tree layout in the file system that has <module> for forwards links and <parent> for backlinks. If <module> does not need full maven coordinates why should parent? Imagine we can use either maven coordinates or a single <relativePath> as parent: <parent> <relativePath>../pom.xml</relativePath> </parent> Than the entire multi-module project can have a single groupId and version set in the root pom. We would be able to control the common version of this logical set of artifacts from one file - no more need to edit dozens of <parent> clauses for every trivial change. All that is needed is for Maven to replace <relativePath> with the actual maven coordinates when we install/deploy. For that matter why don't we make <module> accept a set of maven coordinates as well? Than both the forward and backward links would support two modes: maven coordinates and the repo or local file system and automatic maven coordinate interpolation upon install/deploy.
Hide
Joost den Boer added a comment -

Don't agree with Todor. Using relative path is not a solution since lots of projects have a (company wide) parent pom but are not part of a multi-module project.
As Sylvain said version ranges would be very handy when changing release configuration, license, etc and those are exactly the kind of things you want to configure globally for all company projects. All clients I have worked for have their own main pom in which they define this kind of things. Now, when a new version of that main pom is released, it's a nightmare to change all poms that use it directly and indirectly.

So for me a +1 for this issue.

Show
Joost den Boer added a comment - Don't agree with Todor. Using relative path is not a solution since lots of projects have a (company wide) parent pom but are not part of a multi-module project. As Sylvain said version ranges would be very handy when changing release configuration, license, etc and those are exactly the kind of things you want to configure globally for all company projects. All clients I have worked for have their own main pom in which they define this kind of things. Now, when a new version of that main pom is released, it's a nightmare to change all poms that use it directly and indirectly. So for me a +1 for this issue.
Hide
Alexander Wagner added a comment -

I can agree with Joost den Boer. And it becomes more complex if you have not only one master pom but rather a few like special master poms for differend types of projects.

Show
Alexander Wagner added a comment - I can agree with Joost den Boer. And it becomes more complex if you have not only one master pom but rather a few like special master poms for differend types of projects.
Hide
Mark Michaelis added a comment -

We also need this issue to be resolved - actually MNG-624 (no version = use latest parent) is not enough from my point of view. We need this parent POM for environmental settings (where are repositories and such) which always needs to be up to date. But: We also need to build old projects with this parent POM - and to allow to refactor the property names for example some day we need to have a rule like: In each major version of the parent POM its "API" (i. e.: the property names) stay the same.

Up to now we used settings.xml for this which we handed over through the invoker-plugin. The settings.xml were downloaded and unpacked as dependency - which of course supports version ranges. But the invoker-plugin poses other problems so that it is not a solution for us anylonger.

Show
Mark Michaelis added a comment - We also need this issue to be resolved - actually MNG-624 (no version = use latest parent) is not enough from my point of view. We need this parent POM for environmental settings (where are repositories and such) which always needs to be up to date. But: We also need to build old projects with this parent POM - and to allow to refactor the property names for example some day we need to have a rule like: In each major version of the parent POM its "API" (i. e.: the property names) stay the same. Up to now we used settings.xml for this which we handed over through the invoker-plugin. The settings.xml were downloaded and unpacked as dependency - which of course supports version ranges. But the invoker-plugin poses other problems so that it is not a solution for us anylonger.
Hide
Dmitry Katsubo added a comment -

This is a feature I would like to have as well. In my case I would like to see the "imported" dependencies to work with version ranges.

Show
Dmitry Katsubo added a comment - This is a feature I would like to have as well. In my case I would like to see the "imported" dependencies to work with version ranges.
Hide
Dariusz Czerski added a comment -

It would be very helpful to have a support for specifying parent artifacts version by a property.

<parent>
<artifactId>artifactId</artifactId>
<groupId>groupId</groupId>
<version>${pom.version}</version>
</parent>

This feature opens a possibility to create real centralized dependency management system for multi-project enviroment.
All dependency versions can be keep as parameters (with names in some convention) in special parent project.
Each project defines versions of their dependencies with such a parameters.
Something like this:

<dependency>
<artifactId>artifactId</artifactId>
<groupId>groupId</groupId>
<version>${artifactId.groupId.version}</version>
</dependency>

Then, just by changing value of pom.version, we can automatically change a whole calasspath of all project in the system.
It is very helpful for managing backward compatibility changes.
Of course, the parent project is subject to the normal versioning, it's version changes each time when the new version of some project appear.

Show
Dariusz Czerski added a comment - It would be very helpful to have a support for specifying parent artifacts version by a property. <parent> <artifactId>artifactId</artifactId> <groupId>groupId</groupId> <version>${pom.version}</version> </parent> This feature opens a possibility to create real centralized dependency management system for multi-project enviroment. All dependency versions can be keep as parameters (with names in some convention) in special parent project. Each project defines versions of their dependencies with such a parameters. Something like this: <dependency> <artifactId>artifactId</artifactId> <groupId>groupId</groupId> <version>${artifactId.groupId.version}</version> </dependency> Then, just by changing value of pom.version, we can automatically change a whole calasspath of all project in the system. It is very helpful for managing backward compatibility changes. Of course, the parent project is subject to the normal versioning, it's version changes each time when the new version of some project appear.

People

Vote (21)
Watch (21)

Dates

  • Created:
    Updated: