maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergei Ivanov (JIRA)" <j...@codehaus.org>
Subject [jira] (MNG-3092) resolution of version ranges with non-snapshot bounds can resolve to a snapshot version
Date Mon, 04 Aug 2014 21:49:13 GMT

    [ 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)

Mime
View raw message