maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Gusakov <>
Subject Re: Mercury Version Ranges
Date Wed, 13 Aug 2008 02:31:40 GMT

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 - 
>> 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.

> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message