[
https://jira.codehaus.org/browse/MNG-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=324686#comment-324686
]
Benjamin Busjaeger edited comment on MNG-2199 at 5/5/13 5:45 PM:
-----------------------------------------------------------------
I believe version ranges in parent POMs should be supported, because they
enable an important usage pattern of maven.
I understand the argument for keeping the parent version a fixed quantity. It
makes it possible to store the build repository URL in the parent POM, thus
eliminating the need for an external settings file. This makes builds
self-contained and reproducible.
However, I would argue that this pattern only works well for small maven
projects, because it has several implications. First, it implies that whenever
the parent POM version is updated, all POMs referencing it must be updated as
well with the new version. This greatly reduces the ability to do partial
builds, because each time the parent changes all projects referencing it change
as well. Second, assuming the parent POM contains the repository URL, it must
always be checked out along with the remaining source code. In large
multi-module projects developers may only check out the part of the source tree
that's relevant to them. Finally, it assumes developers actually update the
parent version when they make a change. If they forget to do it, CI builds that
perform the deployment will fail, because the parent versions already exist. In
large, loosely-coupled development organization such an assumption cannot be
made.
Using version ranges in parent references along with the following usage
pattern can alleviate this problem:
- store each parent version in a separate repository
- point to the parent repository in the settings file
- whenever going to an older source version, delete cached parent artifact in
./m2
Note that the parent repository URL in the settings file could be derived from
the current source version to keep builds reproducible. The process can also be
automated to ease the burden on developers. Furthermore, since the parent
references specify ranges, the CI system can automatically append a unique (and
increasing) qualifier when deploying the parent to eliminate the assumption
that developers will update the parent version.
Now it could be argued that in development parent references should use
snapshot versions. Apart from the fact that snapshot version have their own
issues when it comes to large-scale projects, this argument would be
self-contradicting in this context, since snapshots are version ranges of the
form "version-[beginning of time, end of time]".
was (Author: busjaeger):
I believe version ranges in parent POMs should be supported, because they
enable an important usage pattern of maven.
I understand the argument for keeping the parent version a fixed quantity. It
makes it possible to store the build repository URL in the parent POM, thus
eliminating the need for an external settings file. This makes builds
self-contained and reproducible.
However, I would argue that this pattern only works well for small maven
projects, because it has several implications. First, it implies that whenever
the parent POM version is updated, all POMs referencing it must be updated as
well with the new version. This greatly reduces the ability to do partial
builds, because each time the parent changes all projects referencing it change
as well. Second, assuming the parent POM contains the repository URL, it must
always be checked out along with the remaining source code. In large
multi-module projects developers may only check out the part of the source tree
that's relevant to them. Finally, it assumes developers actually update the
parent version when they make a change. If they forget to do it, CI builds that
perform the deployment will fail, because the parent versions already exist. In
large, loosely-coupled development organization such an assumption cannot be
made.
Using version ranges in parent references along with the following usage
pattern can alleviate this problem:
- store each parent version in a separate repository
- point to the parent repository in the settings file
- whenever going to an older source version, delete cached parent artifact in
./m2
Note that the parent repository URL in the settings file could be derived from
the current source version to keep builds reproducible. The process can also be
automated to ease the burden on developers. Furthermore, since the parent
references specify ranges, the CI system can automatically append a unique (and
increasing) qualifier when deploying the parent to eliminate the assumption
that developers will update the parent version.
Now it could be argued that in development parent references should use
snapshot versions. Apart from the fact that snapshot version have their own
issues when it comes to large-scale projects, this argument would be
self-contracting in this context, since snapshots are version ranges of the
form "version-[beginning of time, end of time]".
> Version ranges not supported for parent artifacts
> -------------------------------------------------
>
> Key: MNG-2199
> URL: https://jira.codehaus.org/browse/MNG-2199
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: Inheritance and Interpolation, POM, Reactor and workspace
> Affects Versions: 2.0.3
> Reporter: Christian Schulte
> Fix For: 3.1.1
>
> Attachments: MNG-2199-3.0.4.patch, MNG-2199-3.0.4.patch,
> MNG-2199.patch, MNG-2199.patch, MNG-2199.patch, MNG-2199.patch,
> MNG-2199.patch, MNG-2199.patch
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
