I was trying to use this in a parent version section. Probably not a supported use case?
I have setup my projects so they all eventually derive from a "super parent" that contains things that apply to all my projects. How and where to deploy is an example of something I set there. I'd like to be able to make a change to the parent and have everything automatically pick up the new change. I have it setup to use snapshots now but I was trying to explore this as a possible alternative. The reason is that we have mirrors for central that point to maven-proxy. MP is configured to look at more than central and can usually find our snapshots however central is set to have snapshots turned off. That means everyone needs to define a second repository in their settings to bootstrap and find the parent. Previously, I was able to define all our repos in the super parent. -----Original Message----- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, November 03, 2005 6:58 PM To: Maven Users List Subject: Re: keyword "SNAPSHOT" in depedency version is ignored What was the dependency? Do you have a test case? - Brett On 11/4/05, Brian E. Fox <[EMAIL PROTECTED]> wrote: > I'm not able to make this work. I tried: > [1.1,) > [1.1,] > (1.1,) > > Etc. Each time it is trying to resolve that version exactly as typed. > > -----Original Message----- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Monday, October 31, 2005 3:27 PM > To: Maven Users List > Subject: Re: keyword "SNAPSHOT" in depedency version is ignored > > This functionality already exists in Maven 2.0. > > [1.0,) indicates >= 1.0 > > - Brett > > On 11/1/05, Lukas Theussl <[EMAIL PROTECTED]> wrote: > > Right, but this would be something completely different from the > > current snapshot functionality. > > > > > > As I said in one of my earlier mails, if you want that functionality > > you can open a JIRA request for it (preferably with a patch attached > ;) ). > > And of course, I retain all my reservations about automatic > > dependency > > > upgrade as expressed before. But then, if you want it, it's your > > decision. :) > > > > -Lukas > > > > > > Brian E. Fox wrote: > > > I think maybe what is being asked for is the ability to get the > > > lastest non snapshot build? For example if wagon-ftp changes from > > > 1.0 to 1.1, I want to automatically grab it. Maybe not the best > > > decision, but still a possible option to allow people to choose. I > > > think that in terms of versioning modules you have control over, > this might be preferrable. > > > This way a development team could depend on the latest "sanctioned" > > > version without depending on unstable snapshot builds and without > > > having to manually update all the poms everytime a new module is > published. > > > > > > -----Original Message----- > > > From: Lukas Theussl [mailto:[EMAIL PROTECTED] > > > Sent: Monday, October 31, 2005 1:01 PM > > > To: Maven Users List > > > Subject: Re: keyword "SNAPSHOT" in depedency version is ignored > > > > > > > > > Hi, > > > > > > > > >>What if a released component on remote repository has any bugs? > > > > > > > > > > > > This just underscores my point, no? Generally, I think upgrading > > > (or > > > downgrading) a dependency is always something that should be done > > > very carefully and very consciously, I wouldn't want to have that > > > done automatically. > > > > > > Indicating a SNAPSHOT dependency is only useful if you know that a > > > project is currently under heavy development and you want to stay > > > up > > > > to date with changes on a, say, day-to-day basis (assuming the > > > project publishes SNAPSHOTs that often). This implies that your > > > project itself is currently changing frequently, and if something > > > breaks from one day to the other, you know it might not be due to > > > your own code, but to a changed dependency. As soon as a stable > > > release gets out, you have to indicate explicitly (after testing) > > > that you no longer want to use SNAPSHOTs, but stick to a > > > particular > stable version. > > > > > > > > > > > >>If features of a component do not have to be changed to fix bugs, > > >>I think it's useful to replace this bad component on local > > >>repository with bug fixed component on remote repository > > >>automatically (after agreement). > > > > > > > > > But how would you indicate which component is the good one? A > > > SNAPSHOT always gets you the _latest_ development version, which > > > is actually very rarely the most bug-free one! ;) > > > > > > > > > -Lukas > > > > > > ------------------------------------------------------------------ > > > -- > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > ------------------------------------------------------------------ > > > -- > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
