[
https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314385#comment-314385
]
Scott Sosna commented on MNG-3092:
----------------------------------
I'm surprised of the focus for excluding snapshots; I see snapshots as being
the main use case of ranges, in a development environment as I and at least one
other have described.
For a release artifact, I expect it to have well-known, tested, absolute
dependencies. I don't want dependencies wandering as, for example, new
versions of log4j get released. When the new version of log4j has been
tested/approved/certified, then put out a new POM with a slight version
modification. And I would never expect (or use) a released artifact that used
snapshots.
However, a snapshot artifact should be able to use ranges referring to both
snapshot and released artifacts, as necessary.
Instead of flags to determine inclusion/exclusion of snapshots within ranges,
can we base on the type of artifact?
-For released artifacts, ranges only include releases and no snapshots in
dependency resolution
-For snapshot artifacts, ranges include both release and snapshots in
dependency resolution
The other question is to determine where snapshots fall in a version range. If
you presume that a released artifact represents finality, then snapshots always
are less than the released artifact.
[1.0.0,1.3.0] starts at the 1.0.0 release up through the 1.3.0 release. If the
built artifact is a release, then you'd consider all 1.0.x, 1.1.x, 1.2.x
releases as well as 1.3.0 itself. If the build is a snapshot, you'd also
consider all > 1.0.x snapshots, all 1.1.x snapshots, all 1.2.x snapshots, and
all 1.3.0 snapshots.
[1.0.0-SNAPSHOT,1.0.1] implies building a snapshot artifact, discussed
previously, and should consider all 1.0.0.x snapshots, 1.0.0 release, all
1.0.1.x snapshots and 1.0.1 release.
[Not comprehensive examples, but hopefully enough to move the conversation
forward.]
Now that this has been moved to 3.1.1, how do we continue this conversation so
it doesn't die off again until 3.1.1 is next up. This must be dealt with
eventually. If no resolution is determined, than at least go back to the
functionality as implemented in Maven2. While not perfect, it doesn't break
backwards-compatibility.
> 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
>
>
> 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:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
