[
https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323570#comment-323570
]
Sergei Ivanov commented on MNG-3092:
------------------------------------
@Nils: thanks for reminding of MNG-4751. I do actually remember now that I came
across that ill-fated attempt to alter version resolution behaviour a few years
ago. What is of particular relevance to our current discussion here is the
[e-mail thread|http://www.mail-archive.com/dev@maven.apache.org/msg85652.html]
that is linked from MNG-4751. If you read through the entire e-mail discussion,
you'll come across a [proposed
solution|http://www.mail-archive.com/dev@maven.apache.org/msg85742.html] that
is astonishingly similar to what I suggested above. Only that the original
participants thought it up 2.5 years ago. And it does also look like Benjamin's
proposal was driven by the same or [very similar use
case|http://www.mail-archive.com/dev@maven.apache.org/msg85766.html].
What I do like even more is a separate new {{~/.m2/resolutions.xml}} descriptor
[proposed by
Mark|http://www.mail-archive.com/dev@maven.apache.org/msg85814.html]. For one
thing, it fits well with the other concepts, e.g. settings or toolchains, where
an alternative descriptor can be specified on mvn command line. And
additionally, it solves a whole bunch of problems at once:
* there is no need to modify POM file model or introduce new semantics into
version range definitions
* there is no need to modify settings.xml model
* there is no need to modify version ranges in the project POM to achieve
different resolution behaviour
* complete flexibility to mix and match snapshot/release resolution behaviour
for different groups of upstream dependencies
* and also (looking a bit ahead) the same file could be used to specify
alternative pluggable version ordering rules for artifacts that deviate from
the standard versioning pattern (cf [rule definitions in
versions-maven-plugin|http://mojo.codehaus.org/versions-maven-plugin/version-rules.html])
> Version ranges with non-snapshot bounds can contain snapshot versions
> ---------------------------------------------------------------------
>
> Key: MNG-3092
> URL: https://jira.codehaus.org/browse/MNG-3092
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
> Reporter: Mark Hobson
> Assignee: Jason van Zyl
> Fix For: 3.1.1
>
> Attachments: MNG-3092.patch, MNG-3092.patch
>
>
> Contrary to the 2.0 design docs:
> "Resolution of dependency ranges should not resolve to a snapshot
> (development version) unless it is included as an explicit boundary."
> -- from
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification
> The following is equates to true:
> VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new
> DefaultArtifactVersion( "1.1-SNAPSHOT" ) )
> The attached patch only allows snapshot versions to be contained in a range
> if they are equal to one of the boundaries. Note that this is a strict
> equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT.
--
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
