[
https://jira.codehaus.org/browse/MNG-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308736#comment-308736
]
Christian Schulte edited comment on MNG-2199 at 9/17/12 12:38 PM:
------------------------------------------------------------------
6 years after creating this issue, I still think it would be helpful to have
this supported. For example:
The server name of a repository changes.
=> All POMs of all artifacts in the repository are broken and point to a
non-existing repository.
=> need to re-release all artifacts
=> new artifact versions
=> everyone must update everything
=> at least one full release-cycle wasted
One might say that this kind of problem can be avoided by not adding
repositories to the POM. If you think about that, this just ends in every
environmental property being moved out into settings.xml or somewhere else.
That just leads to non-determinism as well.
Executing 'mvn release:prepare' on a years old tag should work without touching
anything else. It would be non-determinism if this would stop working a few
years later, no ?
The version range is very important here due to the ability to declare an upper
bound. I am not requesting to 'just use the latest parent' but to use the
latest parent from a range (of compatible parent POMs).
During model building, if a POM contains a 'parent' element using a version
range:
=>validate that range has an upper bound and fail the build if unbounded
=>load the latest parent from that range
=>validate the latest parent does not define any 'modules' - fail the build if
it does (maybe use some other information to validate the POM here - a new
packaging used to flag a POM to be used that way e.g.)
=>use that parent
was (Author: schulte2005):
6 years after creating this issue, I still think it would be helpful to
have this supported. For example:
The server name of a repository changes.
=> All POMs of all artifacts in the repository are broken and point to a
non-existing repository.
=> need to re-release all artifacts
=> new artifact versions
=> everyone must update everything
=> at least one full release-cycle wasted
One might say that this kind of problem can be avoided by not adding
repositories to the POM. If you think about that, this just ends in every
environmental property being moved out into settings.xml or somewhere else.
That just leads to non-determinism as well.
Executing 'mvn release:prepare' on a years old tag should work without touching
anything else. It would be non-determinism if this would stop working a few
years later, no ?
The version range is very important here due to the ability to declare an upper
bound. I am not requesting to 'just use the latest parent' but to use the
latest parent from a range (of compatible parent POMs).
> Version ranges not supported for parent artifacts
> -------------------------------------------------
>
> Key: MNG-2199
> URL: https://jira.codehaus.org/browse/MNG-2199
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation, POM, Reactor and workspace
> Affects Versions: 2.0.3
> Reporter: Christian Schulte
> Fix For: Issues to be reviewed for 3.x
>
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
