Mark, I added more files to MNG-3351 (since I'm not sure what will be needed).
This issue also relates to MIDEA-84 (I don't know if you use IntelliJ or not). Regards, -Dave dhoffer wrote: > > Mark, > > That sounds wonderful. I want to help any way I can! > > I attached some test files to MNG-3351 today (pom and settings files). I > don't know if this is enough, if you need more just let me know I will try > to get it for you. > > I stumbled across MNG-2431 recently, this fix will get this one for free. > I will look at your other JIRA's to see if I can comment on those. > > Again, let me know how I can help, I'd be glad to assist any way possible. > > -Dave > > > > mihobson wrote: >> >> I agree with David's comments. Responding to his latest comment on >> MNG-3092 here to keep discussion out of JIRA: >> >> I totally empathise with your situation David. It seems that we're >> both wishing to use version ranges in the same way, the only >> difference is that you've bit the bullet already whereas we're waiting >> for these issues to be resolved before moving to ranges (and in the >> meantime putting up with a lot of manual dependency management). >> >> My current hit list before moving our company to version ranges is: >> MNG-2994, MNG-3092, MNG-3351, MRELEASE-262. I've got some time to try >> moving forward with this again so hopefully we can wrap this up once >> and for all. I'm just getting back up to speed with this issue on the >> latest maven and release plugin, so any relevant findings would be >> welcome. >> >> Cheers, >> >> Mark >> >> On 19/01/2008, dhoffer <[EMAIL PROTECTED]> wrote: >>> >>> I feel this is the most important bug that needs to be fixed. We make >>> heavy >>> use of version ranges and without this fix they are unusable (we have to >>> manually apply a patch to each maven release). >>> >>> "1) You wish a release build with no snapshots which is the normal >>> behaviour >>> and so you just build the trunk of your artifact and it works... >>> optionally >>> the enforcer plugin can ensure that you are not including snapshot >>> dependencies " >>> -No it doesn't work. We can't release using version ranges because of >>> this >>> bug, (that is what this issue is all about). The enforcer is no fix, >>> that >>> doesn't help the release succeed. >>> >>> "2) You wish a dev build with all snapshots enabled so you enable a >>> project >>> configured in your settings.xml that exposes you snapshot repositories >>> Obivously we need to fix... http://jira.codehaus.org/browse/MNG-2994 >>> first" >>> -No, that does not work. If I have already specified what versions >>> (snapshots, version ranges, etc) in my pom that I need, I should not >>> have to >>> do a system fix/workaround of modifying my settings.xml to get the pom >>> to do >>> what it says. But even if I could do this it will not work, because it >>> cannot stop the build from getting snapshots from my local repo. For >>> this >>> workaround to work I would also have to delete my local repo before each >>> build! >>> >>> "3) You wish a dev build but with only a single snapshot... build the >>> project you wish a snapshot of into your local repo... build as in #1" >>> -No again. I don't want to have to build local snapshots first of every >>> snapshot i want to depend on! Furthermore each developer would have to >>> do >>> the same. >>> >>> "If we were to fix MNG-3092 then 2 would not be possible... as you would >>> have to go and edit all your poms to enable snapshots... i have well >>> over >>> 100 artifacts and many dependencies that exist in 40 or more projects... >>> it >>> seems to be that decent continuous integration would not be possible if >>> you >>> fix MNG-3092" >>> -Again we don't want the settings.xml to control if snapshots are >>> visible or >>> not...as discussed, it simply cannot do this job. You have made a >>> process >>> that works for you but in essence you do not use snapshots, rather you >>> make >>> many releases instead so why would you need to go back and modify your >>> 40 >>> projects to include snapshots. Now I can see for others that do use >>> snapshots that it might be nice to have a global override of this >>> behavior. >>> That is, I want/need this bug fixed but I suggest we add a new command >>> line >>> switch that can optionally be used to keep the behavior as it is. >>> >>> I vote to fix this bug. (If it will help I will get my dev team to vote >>> also!) >>> >>> >>> Michael McCallum-3 wrote: >>> > >>> > Back to the origin of the thread >>> > >>> > Version ranges with non-snapshot bounds can contain snapshot versions >>> > http://jira.codehaus.org/browse/MNG-3092 >>> > >>> > >>> > I feel that the current behaviour is correct and can be managed >>> > sufficiently >>> > by profiles. Let me render some scenarios... >>> > >>> > 1) You wish a release build with no snapshots which is the normal >>> > behaviour >>> > and so you just build the trunk of your artifact and it works... >>> > optionally >>> > the enforcer plugin can ensure that you are not including snapshot >>> > dependencies >>> > >>> > 2) You wish a dev build with all snapshots enabled so you enable a >>> project >>> > configured in your settings.xml that exposes you snapshot repositories >>> > Obivously we need to fix... http://jira.codehaus.org/browse/MNG-2994 >>> first >>> > >>> > 3) You wish a dev build but with only a single snapshot... build the >>> > project >>> > you wish a snapshot of into your local repo... build as in #1 >>> > >>> > >>> > If we were to fix MNG-3092 then 2 would not be possible... as you >>> would >>> > have >>> > to go and edit all your poms to enable snapshots... i have well over >>> 100 >>> > artifacts and many dependencies that exist in 40 or more projects... >>> it >>> > seems >>> > to be that decent continuous integration would not be possible if you >>> fix >>> > MNG-3092 >>> > >>> > Can we start a vote for this issue here I guess the same rules as >>> releases >>> > would apply. 72 hours only pmc votes are binding. etc etc >>> > >>> > -- >>> > Michael McCallum >>> > Enterprise Engineer >>> > mailto:[EMAIL PROTECTED] >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: [EMAIL PROTECTED] >>> > For additional commands, e-mail: [EMAIL PROTECTED] >>> > >>> > >>> > >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14967465.html >>> Sent from the Maven Developers mailing list archive at Nabble.com. >>> >>> >>> --------------------------------------------------------------------- >>> 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] >> >> >> > > -- View this message in context: http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p15032985.html Sent from the Maven Developers mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
