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 05:34:30 GMT

Michael McCallum wrote:
> On Wed, 13 Aug 2008 16:58:37 Oleg Gusakov wrote:
>>>> 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)
>>> if you don't allow 1.2-SNAPSHOT how do you actually include them
>>> lets assume that 1-SNAPSHOT < 1-alpha < 1-beta < 1 < 1.1 < 1.1.1
>>> and i say [1,2) then -SNAPSHOT, alpha and beta will not match
>> alpha and beta will match, sn will not, because proposal is to treat
>> them differently. alpha and beta are real releases, while sn is still wip.
> agreed they are real releases but how am i supposed to do automated 
> integration testing trunk to trunk if I can't build a snapshot and push into 
> a local repository and match it?... i would have to actually release the 
> project in order to see if it breaks other things, and if it does its counter 
> productive because i just broke everybody else
> whether or not i end up with snapshots should not be governed by the 
> resolution mechanism but instead by what repositories i provide to it... if I 
> don't want snapshots then there should be no snapshot repositories in the 
> list to resolve from... and perhaps some form of enforcement...
> for example i use the enforcer plugin to make sure that no snapshots get into 
> a project that is being released... i expect developers to use 
> dependency:tree and dependency:resolve to know/check themselves first just in 
> case enforce it with a tool
I have to disagree here: developers should not care what repositories 
they have, or what dependency plugin shows them. They should, instead, 
simply say what they want - and get it. That is why, imho, the core, 
including dependency resolution, should be smarter :)


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