Maven 2 & 3

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.

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.

+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.

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.

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.

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.

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.

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.

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.