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]
