[
https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322919#comment-322919
]
Sergei Ivanov commented on MNG-3092:
------------------------------------
[@Scott|https://jira.codehaus.org/browse/MNG-3092?focusedCommentId=322908&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-322908]
Reverting to dependency management from Maven2 is not an option. Firstly,
because Maven3 uses an entirely new [dependency management
library|http://projects.eclipse.org/projects/technology.aether]. Secondly,
because dependency resolution that involves ranges is broken in Maven2, and we
went through really hard time when we had to adapt our Maven3 project to be
usable by another team, who are still on Maven2. Effectively, we ended up
providing them with an alternative POM, where all version ranges were removed
and versions locked down.
[@Joniec|https://jira.codehaus.org/browse/MNG-3092?focusedCommentId=322912&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-322912]
No, the default behaviour of IDEs will not change. Neither will change the
default behaviour of Maven. One will need to override it with the new switch to
exclude snapshots.
If the team of project B does not override the default behaviour, they will be
both building and developing against 1.0.1-SNAPSHOT. If project B starts using
features from A:1.0.1-SNAPSHOT that are not available in A:1.0.0, then they
will not be able to release (or build with _the switch_ turned on) until
project A releases 1.0.1.
They can set up (like we do) two CI builds, one of which will verify that
project B still builds against the latest released version of project A
(1.0.0), and the other one will check that project B builds against the latest
snapshot of project A(1.0.1-SNAPSHOT).
If team B never want to build or develop against snapshots of A, they can
control it via repository management. Or they should perhaps not use ranges in
the first place (which is probably a good idea if the teams are developing at
different paces and want to have better control of their dependencies).
All in all, they will not be worse off than they are now.
[@Paul|https://jira.codehaus.org/browse/MNG-3092?focusedCommentId=322913&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-322913]
In an ideal world, yes we'd be able to extend Maven POM model and carry on.
Unfortunately, this has a potential to break projects that are still using
previous Maven versions. This is the reason why Maven core team are so
reluctant to introduce any changes to the model.
I agree, we may want to control it in a finer-grained way. Like specifying the
default resolution strategy on the <project> level, and posiibly overriding in
on the individual <dependency> level.
In a real world, this MNG-3092 saga has been going on for ages, and the only
alternative proposed solution involves modifying the POMs on a regular basis to
achieve the desired behaviour. Personally, I do not want to go through tens of
related POMs in my project and introduce snapshots in ranges so that I could
use them in my IDE, and then revert the changes when I want to release them.
This would completely negate any benefits of version ranges. I am proposing a
solution that (1) will not break backward compatibility of maven builds by
default, (2) will not require changes to POM model, (3) will allow to use the
new behaviour without the need to edit POM files (essentially, you can switch
between the old and the new behaviour when using the same POM file). I do also
desperately want a concrete solution to this six year old problem, and I want a
solution that I will be able to start using within my own lifespan.
> 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
