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]
