BTW if you want to _not_ include a snapshot on an open upper bound you can.. [1,2-!)
which will not include 1.0-SNAPSHOT, 1-SNAPSHOT will include any version between 1 and 2 including any 1.2-SNAPSHOT or 1.4-SNAPSHOT will not include 2.0-SNAPSHOT or 2-SNAPSHOT On Thu, 24 Jan 2008 03:42:13 Mark Hobson wrote: > Hi Michael, > > On 23/01/2008, Michael McCallum <[EMAIL PROTECTED]> wrote: > > Firstly IMHO of MNG-3092 is that is it not the right thing for maven in > > general. > > > > I believe with MNG-2994 and appropriate use of profiles to enable and > > disable snapshot repositories you can have everything that you want and > > still maintain the ability to allow any snapshot to be injected when > > desired. There is a little gem that i discovered - or maybe i just > > imagined it - the resolution tree is built from metadata, if you have no > > local metadata and MNG-2994 is fixed then you can control the resolution > > of any artifact by controlling its set of repositories - irrelevant of if > > a snapshot is cached in the local repo. > > > > There is one caveat: the local repository is a merging of two things... a > > local repository and a cache of remote repositories... which is > > unfortunate because that means deploy ends up installing local metadata > > and that results in my view of snapshots and other peoples views of > > snapshots being different. So the act of deploying or installing breaks > > the use of repository selection because local metadata is always used. > > Perhaps the 'local' repository metadata should be maskable as well. > > Strictly speaking there is no reason it should be treated differently. > > There is another caveat in that it's all or nothing. Using a profile > mechanism will switch all range dependencies into snapshot mode, when > typically a developer only wishes to upgrade a couple. How could this > be achieved using profiles? > > > I'm concerned that MNG-3092 is a one way street where better more > > flexible solutions could exist. But having said that if you did fix 3092 > > it would not adversely affect me right now. And if it does... well I'll > > figure something out. > > I can see the theoretical opposition to fixing MNG-3092, but since > it's impractical and unworkable it seems merely academic. I'm open to > suggestions if they still give the efficiency gains that working with > version ranges will provide. > > Cheers, > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]