Oleg Gusakov wrote:
Working on Mercury I faced the necessity to use some standard definition
of a "version range", so I took OSGi definition: OSGi core specs 4.1,
page 39 in April-2007 PDF available on OSGi site - http://osgi.org.
Some interesting ramifications for Maven users:
1). Declaration 1.2.3 means any version X, greater or equal to 1.2.3:
1.2.3 <= X. We are used to a soft version of that in Maven builds -
version can be replaced by a more applicable dependency. But spec states
ANY version: i.e. found in any scanned repository.
Few comments.
First, are you talking about dependencies versions only or the same
rules will be used everywhere, i.e. when looking up plugins and in
dependency/pluginManagement? I would certainly be surprised if maven
started to pick up arbitrary plugin versions. But then again, I would be
surprised if plugin versions were treated differently than dependency
versions.
Also, does not this require introduction of something similar to OSGi
RequiredExecutionEnvironment? I.e. if build is running on Java 5,
anything that can only be handled by Java 6 or newer should be excluded.
Also, have you considered performance implications of this proposal?
Today, maven needs to hit remote repository at most two times, to get
the pom and the artifact itself. Proposed logic seems to require
periodic listing of all versions starting with specified.
2). I strongly feel that failing any explicit ranges, containing
snapshots is a good thing. For instance, dependency declaration
1.2-SNAPSHOT is a range by definition, so I'd rather fail anything like
[1.2-SNAPSHOT,2.0) or [1.0,1.2-SNAPSHOT)
3). Declaration [2.0, 2.1) should exclude 2.1-SNAPSHOT, but include
2.1-alpha-1, etc
Please comment if this does not sound natural or breaks some
well-established usage patterns.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
