We cannot change the behavior, or really even attempt to fiddle with
the code in 2.0.x. We are also planning on entirely replacing this
code with Mercury in the 3.x line. Apache SVN is down so I'll point
you to Mercury when it comes back. Oleg is the one who has implemented
Mercury so he can also point you in the right direction.
On 3-Dec-08, at 4:36 PM, Ian Robertson wrote:
I would like to propose a change to how maven handles version ranges
such as [1.0,), as described in
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict
<http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+ConflictResolution#DependencyMediationandConflictResolution-DependencyVersionRanges
>+<http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges
>Resolution#DependencyMediationandConflictResolution-
DependencyVersionRanges<http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+ConflictResolution#DependencyMediationandConflictResolution-DependencyVersionRanges
>
The current strategy is defined as "Of the overlapping ranges, the
*highest* soft requirement is the version to be used" (emphasis
added). Unfortunately, this leads to temporally unstable builds - a
build of the exact same code base can change from one day to the
next if a new version of one of the dependencies specified with
ranges in its pom is released.
I would propose that the semantics change to "Of the overlapping
ranges, the *lowest* soft requirement is the version to be used."
Consequently, new releases of a project would not change builds of
other projects depending on it (assuming that version numbers
increase instead of decrease with each release). This would
negatively impact those projects wanting to live on the "bleeding
edge", but benefit projects wanting repeatable builds. In practice,
range syntax does not appear to have gained much traction to date,
so this change would hopefully not have substantial impact in terms
of backwards incompatibility. Moreover, providing semantics which
do not introduce instability might increase adoption of the syntax.
If there are objections to this, I would be interested in knowing
what they are. If there are not objections, I would be quite
willing to provide a patch of the code and unit tests.
- Ian Robertson
________________________________
CONFIDENTIALITY NOTICE: This message is intended only for the use
and review of the individual or entity to which it is addressed and
may contain information that is privileged and confidential. If the
reader of this message is not the intended recipient, or the
employee or agent responsible for delivering the message solely to
the intended recipient, you are hereby notified that any
dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in
error, please notify sender immediately by telephone or return
email. Thank you.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Three people can keep a secret provided two of them are dead.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
