[
https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322477#comment-322477
]
Sergei Ivanov commented on MNG-3092:
------------------------------------
For the avoidance of doubt, the following comment does not contain or imply any
humour or jokes.
I totally agree with Tuomas that Kunalkumar's proposed patch would not solve
the problem.
We want to be able to run two different builds: "snapshot vs. snapshot
dependencies" and "snapshot vs. release dependencies" on the same project that
uses defined dependency ranges, but without the need to mess about with the
ranges.
"Snapshot vs. snapshot dependencies" build verifies that the latest changes on
the trunk did not break the project. This build must pick up 1.1.2-SHAPSHOT
from [1.1.0,1.2.0) range, provided that 1.1.2-SHAPSHOT is the latest available
on 1.1.x branch. A complete set of such builds for all projects verifies that
the current tree is consistent and all modules are compatible.
"Snapshot vs. release dependencies" verifies that the project can be released
at this time using the existing released versions of dependencies. This build
must pick up 1.1.1 from the same [1.1.0,1.2.0) range, even if 1.1.2-SHAPSHOT is
available. If such build breaks, it indicates that the upstream projects may
need to be released first.
At present, the only way to achieve a clear separation of snapshot and release
builds is to set up two separate tightly controlled build environments. You can
scroll up for my previous comment, where I described how our CI environment is
set up a greater detail. I cannot tell whether Tuomas's comment contained a
hidden humorous reference to mine, or whether he indeed has a very similar
set-up, but I prefer to think it is the latter.
We only ever use version ranges for our internal dependencies, all external
dependencies and plugins are always pegged to specific versions and any
upgrades are done in a controlled way. My personal preference is that the
inclusion of snashots into version ranges needs to be controlled on the build
level, outside of the POM, so that they can be turned on and off all at once.
For example, it may be a new dedicated command line option or an additional
profile in the settings.xml.
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
