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 -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
