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 :)
Thanks,
Oleg
