[ 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 11:55 AM: ------------------------------------------------------------------ 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). 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 ? > 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