[
https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323420#comment-323420
]
Sergei Ivanov commented on MNG-3092:
------------------------------------
@[Mark|https://jira.codehaus.org/browse/MNG-3092?focusedCommentId=323399&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-323399]:
bq. The workflow with version ranges should be the same as with soft versions
(snapshot, release, snapshot), only now we're changing the upper bound instead.
The release plugin helps automate this currently and there's no reason why it
couldn't also help with version ranges too.
I may be missing the point, but please explain to me how the release plugin is
supposed to manage dependencies in downstream projects. The release plugin only
does update the artifact version in the project that is being released. It does
not update dependency versions in the dependent projects (unless they are
modules in the same reactor) and never did. Moreover, if project A depends on a
snapshot version of project B, the release plugin will fail to release project
A until the dependency on B is changed to release version. One of the reasons
we are using version ranges is to avoid unnecessary switching between snapshot
and release dependencies through editing the POM files.
At the moment, suppose we have the following dependency chain (-> means
"depends on"):
{{A -> B:[2.0,3.0) -> C:[1.3,1.4) -> D:[3.5,4.0)}}
Suppose one makes a trivial bug fix to upstream library D and wants to test its
effect locally in downstream project A before releasing both D and A. At the
moment, any change in D is automatically picked up by version resolution in A,
as long as the snapshot version of D stays in the defined range.
If we go down the route you are suggesting, does that mean that one would need
to change the whole chain of dependencies to the following, and build local
snapshots of all 4 projects in the reverse order?
{{A -> B:[2.0-SNAPSHOT,3.0) -> C:[1.3-SHAPSHOT,1.4) -> D:[3.5-SNAPSHOT,4.0)}}
Suppose it is not a chain, but a graph of dependencies, which is more like we
typically have in the real world. Imagine a typical developer working through
the graph, updating dependency versions in POMs to snapshots along the
effective dependency path? This is where blind hatred of Maven starts. And how
will version resolution work if one branch of the graph allows snapshots in
ranges and the other does not?
Again, I apologise if I am missing the point, but can somebody please provide
an example of a detailed development and release workflow if we go down the
route of explicitly specifying snapshots in version ranges.
> 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
