[
https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=350956#comment-350956
]
Sergei Ivanov commented on MNG-3092:
------------------------------------
@Richard:
Regarding your yesterday's comment _"setting up HEAD builds where snapshots are
included (and you want them included) vs a stable build where you aren't
including snapshot builds and where you don't want them to be *without changing
your pom*"_. This is exactly what is not possible now. The whole premise of
version ranges is to reduce the amount of POM changes due to shifting
dependency versions. Typically you only change your POM if you need to upgrade
to the next version range. I do not want to change my settings.xml or keep two
alternative versions either.
At the moment the only way to keep snapshots away from release builds without
changing the POMs is to have two separate settings.xml files pointing to
different local repositories for snapshot and release builds. You end up
downloading the internet twice, but it is a price you pay for build stability.
While it is certainly doable in the CI environment, you are still stuffed in
your local development if you accidentally pick up or install a snapshot that
spoils your version range. Having 1.1.2 and 1.1.3-SNAPSHOT in the local repo
will always resolve [1.1, 1.2) to 1.1.3-SNAPSHOT and there is no way around it
apart from purging the offending version from the local repo manually.
Probably worth mentioning that some core plugins still occasionally fail on
version ranges, see for example MDEP-364 and MDEP-373. Or MRRESOURCES-58, which
is fixed now, but took almost 1.5 years to apply the patch.
I agree that in fluid projects version ranges work pretty well, as long as you
avoid the trip wires (and know what to look out for). I guess, I could also
write a small book dedicated to all the various workarounds we had to
implement, but I would never be brave enough to claim that "dependency ranges
in Maven work beautifully out of the box", because that is a lie.
@Scott: apologies, my earlier comment about this issue having become a feature
was lacking a <sarcasm> tag. I do remember that you and I are viewing this
issue from completely different perspectives, but I guess we both hoped that
the core Maven team would contribute their insights to this discussion. Which
alas never happened.
> resolution of version ranges with non-snapshot bounds can resolve to a
> snapshot version
> ---------------------------------------------------------------------------------------
>
> Key: MNG-3092
> URL: https://jira.codehaus.org/browse/MNG-3092
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
> Reporter: Mark Hobson
> Assignee: Jason van Zyl
> Fix For: 3.2.x
>
> 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 was sent by Atlassian JIRA
(v6.1.6#6162)
