so you are saying that A-2.0-SNAPSHOT uses B [1,2-!) and someone deploys B 1.4.1-SNAPSHOT and that overrides B 2.0-SNAPSHOT and B 1.4 or just that it overrides B1.4?
Depends on your use case... as to how you would deal with that. And one of the reasons why I don't want mng-3092 because I can CI for this problem at the moment. <digression> well you do need to be careful but the same it true even if you have version ranges for releases... mvn depedency:resolve is your friend... when creating patched assemblies you need to confirm that any changes are ok... its not sufficient just to exclude snapshots... because any released version could also change the behaviour of the system... </digression> On Thu, 24 Jan 2008 08:41:48 Stephen Connolly wrote: > 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] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
