maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Gusakov <oleg.subscripti...@gmail.com>
Subject Re: Mercury Version Ranges
Date Wed, 13 Aug 2008 13:45:04 GMT


Mark Hobson wrote:
> Hi Oleg,
>
> 2008/8/13 Oleg Gusakov <oleg.subscriptions@gmail.com>:
>   
>> 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.
>>     
>
> Isn't this essentially what we have now with Maven?  A soft dependency
> of 1.2.3 can be replaced by any other version as determined by the
> conflict resolution mechanism (currently nearest-wins).  If OSGi
> mandates that soft versions can only be resolved to versions greater
> or equal to the suggested version then this seems more robust than
> what we currently have.
>   
Mark - this is the same if one excludes repositories and lives within 
pre-existing version set: like Maven having only local repo and OSGi 
having one OBR file.

If we add a variable - repositories that constantly change, then we 
start wondering what to do and OSGi joins this discussion as soon as 
they add this feature.
>   
>> 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)
>>     
>
> Are you referring to failing at release time here?  I agree that a
> project containing dependencies with version ranges that contain
> snapshots should not be allowed to be released.
>
>   
>> 3). Declaration [2.0, 2.1) should exclude 2.1-SNAPSHOT, but include
>> 2.1-alpha-1, etc
>>     
>
> Welcome to the debate :)  I say that a version range should only
> resolve to a snapshot if it is included as an explicit boundary.  See
> http://jira.codehaus.org/browse/MNG-3092
>
> You may also be interested in the other issues on my hit list for
> being able to use version ranges in Maven:
> http://jira.codehaus.org/browse/MNG-2994
> http://jira.codehaus.org/browse/MRELEASE-262
> http://jira.codehaus.org/browse/MRELEASE-318
>
> Regarding Michael's suggestion of using repositories to control
> whether ranges resolve to snapshots or not: the problem with this is
> that it's an all or nothing approach.
>   
I agree, and it's also too demanding an approach; it requires users to 
know a lot of details. In my opinion - build system should be more 
transparent and less intrusive.

> For example, say I need to fix a bug in Project A 3.0 that depends on
> Project B 2.0, amongst many other dependencies.  I take A 3.0 and
> determine that the bug is in B 2.0, so I want to update the dependency
> of B in A to 2.1-SNAPSHOT.  Assuming that this range was initially
> declared as B[2.0,3.0), using the repository approach I would just
> enable snapshot repositories for the range to resolve to my new
> work-in-progress B 2.1-SNAPSHOT.  This works, but it would also open
> the gates for all other ranged dependencies to resolve to snapshots
> too, which I certainly don't want.  Whereas if ranges behaved as I've
> described, then we would just update B to [2.0,2.1-SNAPSHOT) during
> development and then reinstate [2.0,3.0) once the fixed B 2.1 has been
> released.
>
>   
Why not using 2.1-SNAPSHOT directly? Including it into the range is 
messier solution if you ask me. In both cases you have to change the 
pom, so there is not distinct advantage in either .

BTW - thanks for the references!

Oleg

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