maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Milos Kleint" <>
Subject Re: Mercury Version Ranges
Date Wed, 13 Aug 2008 05:44:18 GMT
On Wed, Aug 13, 2008 at 7:34 AM, Oleg Gusakov
<> wrote:
> 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 <
>>>> 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 :)

no tool can substitute people and people should be in power. Will
there be ways to override the "smartness" of the tool?


> Thanks,
> Oleg

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

View raw message