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]

Reply via email to