Igor Fedorenko wrote:
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.
Current implementation (let's call it 2.0) is promiscuous inside the
"dirty" dependency tree - all possible versions before conflict
resolution. But for plugins - the first plugin found wins. I would say -
we should be consistent and *treat plugins the same as dependencies*.
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.
This is a nice optional feature that is a topic for a different
discussion. Now I'd like to narrow this to just "how to declare and
interpret dependency versions"
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.
All enhancements require more of something, like HD just asking for a
bigger TV :) This could be mitigated by:
- intelligent repository manager that does version interpretation by
client's request
- making "OSGi compliant" behavior optional, so that users have an
option to curb the bandwidth appetite of the client
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.
What do you think about snapshots in ranges? Or - better - prohibiting
snapshot in ranges.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
