But that will bugger you up... You are working on the version 2 branch, there is no 2.0 released, only 2.0-SNAPSHOT... you don't care as it is still new and you are happy to use the last stable release, 1.4...
Now there is some work that is needed for the 1.4 service pack, so 1.4.1-SNAPSHOT arrives and bang! you are scuppered On Jan 23, 2008 7:31 PM, Michael McCallum <[EMAIL PROTECTED]> wrote: > 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] > >
