proposed structural change to the source repo
Since we're moving tomorrow anyway, I'd like to propose making the following change subsequently: /archiva /archiva-docs /archiva-jetty /archiva-modules .. current structure under here This means we can retain the one release, one build - but all the Java code sites under -modules. This allows us to put all the Java code reporting in there, and not pollute the -docs and the distro with it. I think more changes can be made to the structure of -modules, but that can be done at a later time. Any objections? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: proposed structural change to the source repo
Let's go !!! Arnaud On Thu, Mar 27, 2008 at 9:36 PM, Brett Porter [EMAIL PROTECTED] wrote: Since we're moving tomorrow anyway, I'd like to propose making the following change subsequently: /archiva /archiva-docs /archiva-jetty /archiva-modules .. current structure under here This means we can retain the one release, one build - but all the Java code sites under -modules. This allows us to put all the Java code reporting in there, and not pollute the -docs and the distro with it. I think more changes can be made to the structure of -modules, but that can be done at a later time. Any objections? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
Re: svn commit: r641729 - /maven/archiva/trunk/archiva-web/archiva-standalone/archiva-jetty/pom.xml
I was able to build the jetty bundle. The problem came up when I ran it. I'm getting a jasper compiler exception when I tried to access the application, so I added the dependency back and everything worked fine again :-) Thanks, Deng On Fri, Mar 28, 2008 at 2:43 AM, Brett Porter [EMAIL PROTECTED] wrote: That's weird - it worked without it for me. What was the error you got? This adds a bit to the download, but I'm happy enough to keep it in, it should also improve the performance. Cheers, Brett On 27/03/2008, at 6:50 PM, [EMAIL PROTECTED] wrote: Author: oching Date: Thu Mar 27 00:50:11 2008 New Revision: 641729 URL: http://svn.apache.org/viewvc?rev=641729view=rev Log: [MRM-688] -adding back jasper-compiler-jdt as dependency (this is needed for jsp support) Modified: maven/archiva/trunk/archiva-web/archiva-standalone/archiva-jetty/ pom.xml Modified: maven/archiva/trunk/archiva-web/archiva-standalone/archiva- jetty/pom.xml URL: http://svn.apache.org/viewvc/maven/archiva/trunk/archiva-web/archiva-standalone/archiva-jetty/pom.xml?rev=641729r1=641728r2=641729view=diff = = = = = = = = == --- maven/archiva/trunk/archiva-web/archiva-standalone/archiva-jetty/ pom.xml (original) +++ maven/archiva/trunk/archiva-web/archiva-standalone/archiva-jetty/ pom.xml Thu Mar 27 00:50:11 2008 @@ -123,6 +123,12 @@ version1.0.1/version scoperuntime/scope /dependency +dependency + groupIdtomcat/groupId + artifactIdjasper-compiler-jdt/artifactId + version5.5.15/version + scoperuntime/scope +/dependency /dependencies build plugins -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: proposed structural change to the source repo
I like it. Lets do it now! I'll update other sites with references to our new Archiva svn root. (like ohloh and statsvn) - Joakim Brett Porter wrote: Since we're moving tomorrow anyway, I'd like to propose making the following change subsequently: /archiva /archiva-docs /archiva-jetty /archiva-modules .. current structure under here This means we can retain the one release, one build - but all the Java code sites under -modules. This allows us to put all the Java code reporting in there, and not pollute the -docs and the distro with it. I think more changes can be made to the structure of -modules, but that can be done at a later time. Any objections? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: [pre vote take 3] 2.0.9-RC3
+1 Tested with my local projects with no issue. 2008/3/26, Raphaël Piéroni [EMAIL PROTECTED]: +1 the bundle worked fine to build the archetype plugin. Raphaël 2008/3/26, Raphaël Piéroni [EMAIL PROTECTED]: +1 for the new process. not yet tested the bundle. Raphaël 2008/3/26, Brian E. Fox [EMAIL PROTECTED]: We fixed the regressions identified last week with the plugin tools and reporting impl. The new 2.0.9 is staged at http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa che-maven/2.0.9-RC3/ You'll notice that this one has an RC qualifier attached to it. Since what I've actually been staging hasn't been for an official vote, it makes more sense to have actual deterministic numbers on them instead of continuously rolling back and forth between .10 and .9. The other significant reason it has a qualifier is that I want to solicit feedback from the users list without potentially getting multiple versions out there called 2.0.9. My new mantra for the maven release is no more regressions. To that end, what I intend to do is let the RC sit here for a day. If no one turns up anything new (it should be good since this is really attempt #3), then I'll email the user list to solicit feedback. Naturally we'll probably get a slew of can you fix xyz but the only thing that we will consider at this point would be a regression from 2.0.8 to the current RC. If something is identified then we should consider fixing it and re-releasing RC4. I think that having the users more involved in testing the RCs is the only way to really identify and eliminate regressions. If someone identifies a regression after the fact and didn't speak up or try it, well that's unfortunate but it'll have to wait. The RC can sit with the users for 3 days. If nothing turns up, then I'll restage with a final release tag and we can do a formal vote. Assuming this is all successful, then I'll document a more formal Core release procedure that we can follow going forward. Here's the list of issues fixed in the latest RC: Release Notes - Maven 2 - Version 2.0.9 ** Bug * [MNG-1412] - dependency sorting in classpath * [MNG-1914] - Wrong url in error message when using a mirror * [MNG-2123] - NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range * [MNG-2145] - Plugins' dependencies are not always checked * [MNG-2178] - incorrect M2_HOME guess in mvn.bat * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when profiles section is missing or empty * [MNG-2339] - ${project.*} are interpreted in the wrong place * [MNG-2744] - checksum comparison should be case-insensitive * [MNG-2809] - Can't activate a profile by checking for the presence of a file in ${user.home} * [MNG-2848] - Environment variables in profile activation not working * [MNG-2861] - NullPointerException in DefaultArtifactCollector for relocated resolvedArtifacts with different version ranges and available versions. * [MNG-2925] - NullPointerException in PluginDescriptor.getMojo() if there's no mojo in pom.xml * [MNG-2928] - Null pointer exeception when introducing version range [major.minor.build-SNAPSHOT,) * [MNG-2972] - Ignores version of plugin dependency specified in my pom * [MNG-3086] - NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136) * [MNG-3099] - Profiles ignored when working with non-projects (such as archetype:create) * [MNG-3111] - Classpath order incorrect * [MNG-3156] - NullPointerException with mvn dependency:sources * [MNG-3221] - Infinite loop in DefaultLifecycleExecutor * [MNG-3259] - Regression: Maven drops dependencies in multi-module build * [MNG-3286] - execution.inherited field is ignored * [MNG-3288] - Invalid systemPath allows build to continue--failing in later phase. * [MNG-3296] - mvn.bat looses error code on windows NT type platforms * [MNG-3310] - JAVACMD set incorrectly when JAVA_HOME is not set * [MNG-3316] - Barfs at attribues named .*encoding * [MNG-3354] - mvn.bat incorrectly detects OS on Windows NT or XP with Novell login * [MNG-3355] - CLONE -${pom.build.sourceDirectory} and ${pom.build.testSourceDirectory} no longer recognized * [MNG-3365] - Remove trailing-backslashes from M2_HOME in mvn.bat * [MNG-3394] - Plugin versions inherited via
Re: [pre vote take 3] 2.0.9-RC3
same here, no apparent issues with RC4 on my projects. On Thu, Mar 27, 2008 at 9:27 AM, nicolas de loof [EMAIL PROTECTED] wrote: +1 Tested with my local projects with no issue. 2008/3/26, Raphaël Piéroni [EMAIL PROTECTED]: +1 the bundle worked fine to build the archetype plugin. Raphaël 2008/3/26, Raphaël Piéroni [EMAIL PROTECTED]: +1 for the new process. not yet tested the bundle. Raphaël 2008/3/26, Brian E. Fox [EMAIL PROTECTED]: We fixed the regressions identified last week with the plugin tools and reporting impl. The new 2.0.9 is staged at http://people.apache.org/~brianf/staging-repository/org/apache/maven/apahttp://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa che-maven/2.0.9-RC3/ You'll notice that this one has an RC qualifier attached to it. Since what I've actually been staging hasn't been for an official vote, it makes more sense to have actual deterministic numbers on them instead of continuously rolling back and forth between .10 and .9. The other significant reason it has a qualifier is that I want to solicit feedback from the users list without potentially getting multiple versions out there called 2.0.9. My new mantra for the maven release is no more regressions. To that end, what I intend to do is let the RC sit here for a day. If no one turns up anything new (it should be good since this is really attempt #3), then I'll email the user list to solicit feedback. Naturally we'll probably get a slew of can you fix xyz but the only thing that we will consider at this point would be a regression from 2.0.8 to the current RC. If something is identified then we should consider fixing it and re-releasing RC4. I think that having the users more involved in testing the RCs is the only way to really identify and eliminate regressions. If someone identifies a regression after the fact and didn't speak up or try it, well that's unfortunate but it'll have to wait. The RC can sit with the users for 3 days. If nothing turns up, then I'll restage with a final release tag and we can do a formal vote. Assuming this is all successful, then I'll document a more formal Core release procedure that we can follow going forward. Here's the list of issues fixed in the latest RC: Release Notes - Maven 2 - Version 2.0.9 ** Bug * [MNG-1412] - dependency sorting in classpath * [MNG-1914] - Wrong url in error message when using a mirror * [MNG-2123] - NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range * [MNG-2145] - Plugins' dependencies are not always checked * [MNG-2178] - incorrect M2_HOME guess in mvn.bat * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when profiles section is missing or empty * [MNG-2339] - ${project.*} are interpreted in the wrong place * [MNG-2744] - checksum comparison should be case-insensitive * [MNG-2809] - Can't activate a profile by checking for the presence of a file in ${user.home} * [MNG-2848] - Environment variables in profile activation not working * [MNG-2861] - NullPointerException in DefaultArtifactCollector for relocated resolvedArtifacts with different version ranges and available versions. * [MNG-2925] - NullPointerException in PluginDescriptor.getMojo () if there's no mojo in pom.xml * [MNG-2928] - Null pointer exeception when introducing version range [major.minor.build-SNAPSHOT,) * [MNG-2972] - Ignores version of plugin dependency specified in my pom * [MNG-3086] - NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136) * [MNG-3099] - Profiles ignored when working with non-projects (such as archetype:create) * [MNG-3111] - Classpath order incorrect * [MNG-3156] - NullPointerException with mvn dependency:sources * [MNG-3221] - Infinite loop in DefaultLifecycleExecutor * [MNG-3259] - Regression: Maven drops dependencies in multi-module build * [MNG-3286] - execution.inherited field is ignored * [MNG-3288] - Invalid systemPath allows build to continue--failing in later phase. * [MNG-3296] - mvn.bat looses error code on windows NT type platforms * [MNG-3310] - JAVACMD set incorrectly when JAVA_HOME is not set * [MNG-3316] - Barfs at attribues named
Re: [pre vote take 3] 2.0.9-RC3
I've built mevenide with it and it worked fine. +1 Milos On Thu, Mar 27, 2008 at 9:59 AM, Jorg Heymans [EMAIL PROTECTED] wrote: same here, no apparent issues with RC4 on my projects. On Thu, Mar 27, 2008 at 9:27 AM, nicolas de loof [EMAIL PROTECTED] wrote: +1 Tested with my local projects with no issue. 2008/3/26, Raphaël Piéroni [EMAIL PROTECTED]: +1 the bundle worked fine to build the archetype plugin. Raphaël 2008/3/26, Raphaël Piéroni [EMAIL PROTECTED]: +1 for the new process. not yet tested the bundle. Raphaël 2008/3/26, Brian E. Fox [EMAIL PROTECTED]: We fixed the regressions identified last week with the plugin tools and reporting impl. The new 2.0.9 is staged at http://people.apache.org/~brianf/staging-repository/org/apache/maven/apahttp://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa che-maven/2.0.9-RC3/ You'll notice that this one has an RC qualifier attached to it. Since what I've actually been staging hasn't been for an official vote, it makes more sense to have actual deterministic numbers on them instead of continuously rolling back and forth between .10 and .9. The other significant reason it has a qualifier is that I want to solicit feedback from the users list without potentially getting multiple versions out there called 2.0.9. My new mantra for the maven release is no more regressions. To that end, what I intend to do is let the RC sit here for a day. If no one turns up anything new (it should be good since this is really attempt #3), then I'll email the user list to solicit feedback. Naturally we'll probably get a slew of can you fix xyz but the only thing that we will consider at this point would be a regression from 2.0.8 to the current RC. If something is identified then we should consider fixing it and re-releasing RC4. I think that having the users more involved in testing the RCs is the only way to really identify and eliminate regressions. If someone identifies a regression after the fact and didn't speak up or try it, well that's unfortunate but it'll have to wait. The RC can sit with the users for 3 days. If nothing turns up, then I'll restage with a final release tag and we can do a formal vote. Assuming this is all successful, then I'll document a more formal Core release procedure that we can follow going forward. Here's the list of issues fixed in the latest RC: Release Notes - Maven 2 - Version 2.0.9 ** Bug * [MNG-1412] - dependency sorting in classpath * [MNG-1914] - Wrong url in error message when using a mirror * [MNG-2123] - NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range * [MNG-2145] - Plugins' dependencies are not always checked * [MNG-2178] - incorrect M2_HOME guess in mvn.bat * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when profiles section is missing or empty * [MNG-2339] - ${project.*} are interpreted in the wrong place * [MNG-2744] - checksum comparison should be case-insensitive * [MNG-2809] - Can't activate a profile by checking for the presence of a file in ${user.home} * [MNG-2848] - Environment variables in profile activation not working * [MNG-2861] - NullPointerException in DefaultArtifactCollector for relocated resolvedArtifacts with different version ranges and available versions. * [MNG-2925] - NullPointerException in PluginDescriptor.getMojo () if there's no mojo in pom.xml * [MNG-2928] - Null pointer exeception when introducing version range [major.minor.build-SNAPSHOT,) * [MNG-2972] - Ignores version of plugin dependency specified in my pom * [MNG-3086] - NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136) * [MNG-3099] - Profiles ignored when working with non-projects (such as archetype:create) * [MNG-3111] - Classpath order incorrect * [MNG-3156] - NullPointerException with mvn dependency:sources * [MNG-3221] - Infinite loop in DefaultLifecycleExecutor * [MNG-3259] - Regression: Maven
Re: i am facing problem when i using tomcat 6.0 + maven2
[EMAIL PROTECTED] wrote: I am very sorry, I need help urgently I have problem with using tomcat 6.0.14 with maven2 + cargo. Can u help or give suggestions Thanks Regards, Sridhar Thota, Hi, According to Cargo website at http://cargo.codehaus.org/, it seems that Tomcat 6.0 is not supported (although it may still work, never tried it). However, we have been using tomcat-maven-plugin from Codehaus Mojo with success, check it out: http://mojo.codehaus.org/tomcat-maven-plugin/introduction.html hope this helps, Andrius P.S. Please create entirely new message next time - do not reply to an existing one if it is not a reply. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: unsubscribe
Thanks, Although it was actually the notifications list I wanted to be unsubscribed from...:) Dennis Lundberg wrote: Nino Saturnino Martinez Vazquez Wael wrote: Info on how to subscribe to and unsubscribe from Maven mailing lists can be found on this page: http://maven.apache.org/mail-lists.html -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pre vote take 3] 2.0.9-RC3
Hi, Testing on corporate projects and build fine. +1 I have just noticed a change (regression ?). We have a corporate plugin. In the pom it's configured as this : plugin .. configuration subject.. - ${version} ../subject We use it with mvn blabla -Dversion=here a version. The value has changed : - with mvn 2.0.8 : the value from the cli is used. - with this RC : the ${version} is replaced with the current pom.version. It's not a blocking issue because we can easily replace with : subject.. - ${releaseVersion} ../subject and use mvn blabla -DreleaseVersion= But I hope there is no other side effect. -- Olivier 2008/3/26, Brian E. Fox [EMAIL PROTECTED]: We fixed the regressions identified last week with the plugin tools and reporting impl. The new 2.0.9 is staged at http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa che-maven/2.0.9-RC3/ You'll notice that this one has an RC qualifier attached to it. Since what I've actually been staging hasn't been for an official vote, it makes more sense to have actual deterministic numbers on them instead of continuously rolling back and forth between .10 and .9. The other significant reason it has a qualifier is that I want to solicit feedback from the users list without potentially getting multiple versions out there called 2.0.9. My new mantra for the maven release is no more regressions. To that end, what I intend to do is let the RC sit here for a day. If no one turns up anything new (it should be good since this is really attempt #3), then I'll email the user list to solicit feedback. Naturally we'll probably get a slew of can you fix xyz but the only thing that we will consider at this point would be a regression from 2.0.8 to the current RC. If something is identified then we should consider fixing it and re-releasing RC4. I think that having the users more involved in testing the RCs is the only way to really identify and eliminate regressions. If someone identifies a regression after the fact and didn't speak up or try it, well that's unfortunate but it'll have to wait. The RC can sit with the users for 3 days. If nothing turns up, then I'll restage with a final release tag and we can do a formal vote. Assuming this is all successful, then I'll document a more formal Core release procedure that we can follow going forward. Here's the list of issues fixed in the latest RC: Release Notes - Maven 2 - Version 2.0.9 ** Bug * [MNG-1412] - dependency sorting in classpath * [MNG-1914] - Wrong url in error message when using a mirror * [MNG-2123] - NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range * [MNG-2145] - Plugins' dependencies are not always checked * [MNG-2178] - incorrect M2_HOME guess in mvn.bat * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when profiles section is missing or empty * [MNG-2339] - ${project.*} are interpreted in the wrong place * [MNG-2744] - checksum comparison should be case-insensitive * [MNG-2809] - Can't activate a profile by checking for the presence of a file in ${user.home} * [MNG-2848] - Environment variables in profile activation not working * [MNG-2861] - NullPointerException in DefaultArtifactCollector for relocated resolvedArtifacts with different version ranges and available versions. * [MNG-2925] - NullPointerException in PluginDescriptor.getMojo() if there's no mojo in pom.xml * [MNG-2928] - Null pointer exeception when introducing version range [major.minor.build-SNAPSHOT,) * [MNG-2972] - Ignores version of plugin dependency specified in my pom * [MNG-3086] - NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136) * [MNG-3099] - Profiles ignored when working with non-projects (such as archetype:create) * [MNG-3111] - Classpath order incorrect * [MNG-3156] - NullPointerException with mvn dependency:sources * [MNG-3221] - Infinite loop in DefaultLifecycleExecutor * [MNG-3259] - Regression: Maven drops dependencies in multi-module build * [MNG-3286] - execution.inherited field is ignored * [MNG-3288] - Invalid systemPath allows build to continue--failing in later phase. * [MNG-3296] - mvn.bat looses error code on windows NT type platforms * [MNG-3310] - JAVACMD set incorrectly when JAVA_HOME is not set * [MNG-3316] - Barfs at attribues named .*encoding * [MNG-3354] - mvn.bat incorrectly detects OS on Windows NT or XP with Novell login * [MNG-3355] - CLONE -${pom.build.sourceDirectory} and ${pom.build.testSourceDirectory} no longer recognized * [MNG-3365] - Remove trailing-backslashes from M2_HOME in mvn.bat * [MNG-3394] - Plugin versions inherited via
Re: [pre vote take 3] 2.0.9-RC3
Tested on my projects, works fine. Here's my +1 for RC4. -- Fabrice - [EMAIL PROTECTED] - On Thu, Mar 27, 2008 at 4:26 AM, Brian E. Fox [EMAIL PROTECTED] wrote: Sejal, James, could you try with this informal RC? http://people.apache.org/~brianf/2.0.9/http://people.apache.org/%7Ebrianf/2.0.9/(still uploading, give a few mins) This should get you past MNG-3119 so we can see if everything else is good before cutting the RC4 for real. Thanks for testing. --Brian
RE: [pre vote take 3] 2.0.9-RC3
Hrm. It's probably a good idea to use a different property, but we should understand why this changed before going further. John, any ideas? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Lamy Sent: Thursday, March 27, 2008 6:56 AM To: Maven Developers List Subject: Re: [pre vote take 3] 2.0.9-RC3 Hi, Testing on corporate projects and build fine. +1 I have just noticed a change (regression ?). We have a corporate plugin. In the pom it's configured as this : plugin .. configuration subject.. - ${version} ../subject We use it with mvn blabla -Dversion=here a version. The value has changed : - with mvn 2.0.8 : the value from the cli is used. - with this RC : the ${version} is replaced with the current pom.version. It's not a blocking issue because we can easily replace with : subject.. - ${releaseVersion} ../subject and use mvn blabla -DreleaseVersion= But I hope there is no other side effect. -- Olivier 2008/3/26, Brian E. Fox [EMAIL PROTECTED]: We fixed the regressions identified last week with the plugin tools and reporting impl. The new 2.0.9 is staged at http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa che-maven/2.0.9-RC3/ You'll notice that this one has an RC qualifier attached to it. Since what I've actually been staging hasn't been for an official vote, it makes more sense to have actual deterministic numbers on them instead of continuously rolling back and forth between .10 and .9. The other significant reason it has a qualifier is that I want to solicit feedback from the users list without potentially getting multiple versions out there called 2.0.9. My new mantra for the maven release is no more regressions. To that end, what I intend to do is let the RC sit here for a day. If no one turns up anything new (it should be good since this is really attempt #3), then I'll email the user list to solicit feedback. Naturally we'll probably get a slew of can you fix xyz but the only thing that we will consider at this point would be a regression from 2.0.8 to the current RC. If something is identified then we should consider fixing it and re-releasing RC4. I think that having the users more involved in testing the RCs is the only way to really identify and eliminate regressions. If someone identifies a regression after the fact and didn't speak up or try it, well that's unfortunate but it'll have to wait. The RC can sit with the users for 3 days. If nothing turns up, then I'll restage with a final release tag and we can do a formal vote. Assuming this is all successful, then I'll document a more formal Core release procedure that we can follow going forward. Here's the list of issues fixed in the latest RC: Release Notes - Maven 2 - Version 2.0.9 ** Bug * [MNG-1412] - dependency sorting in classpath * [MNG-1914] - Wrong url in error message when using a mirror * [MNG-2123] - NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range * [MNG-2145] - Plugins' dependencies are not always checked * [MNG-2178] - incorrect M2_HOME guess in mvn.bat * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when profiles section is missing or empty * [MNG-2339] - ${project.*} are interpreted in the wrong place * [MNG-2744] - checksum comparison should be case-insensitive * [MNG-2809] - Can't activate a profile by checking for the presence of a file in ${user.home} * [MNG-2848] - Environment variables in profile activation not working * [MNG-2861] - NullPointerException in DefaultArtifactCollector for relocated resolvedArtifacts with different version ranges and available versions. * [MNG-2925] - NullPointerException in PluginDescriptor.getMojo() if there's no mojo in pom.xml * [MNG-2928] - Null pointer exeception when introducing version range [major.minor.build-SNAPSHOT,) * [MNG-2972] - Ignores version of plugin dependency specified in my pom * [MNG-3086] - NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136) * [MNG-3099] - Profiles ignored when working with non-projects (such as archetype:create) * [MNG-3111] - Classpath order incorrect * [MNG-3156] - NullPointerException with mvn dependency:sources * [MNG-3221] - Infinite loop in DefaultLifecycleExecutor * [MNG-3259] - Regression: Maven drops dependencies in multi-module build * [MNG-3286] - execution.inherited field is ignored * [MNG-3288] - Invalid systemPath allows build to continue--failing in later phase. * [MNG-3296] - mvn.bat looses error code on windows NT type platforms * [MNG-3310] - JAVACMD set incorrectly when JAVA_HOME is not set * [MNG-3316] - Barfs at attribues named
Re: [pre vote take 3] 2.0.9-RC3
Hmm, I'll have to do some homework on this one, but yeah, it looks like the interpolation changes I put in to get the path-translation in place. I'll have to see if I can work up a test case for this, and try to track down that original issue. Let me get to work on it and I'll see how fast I can come up with something. -john On Mar 27, 2008, at 8:09 AM, Brian E. Fox wrote: Hrm. It's probably a good idea to use a different property, but we should understand why this changed before going further. John, any ideas? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Lamy Sent: Thursday, March 27, 2008 6:56 AM To: Maven Developers List Subject: Re: [pre vote take 3] 2.0.9-RC3 Hi, Testing on corporate projects and build fine. +1 I have just noticed a change (regression ?). We have a corporate plugin. In the pom it's configured as this : plugin .. configuration subject.. - ${version} ../subject We use it with mvn blabla -Dversion=here a version. The value has changed : - with mvn 2.0.8 : the value from the cli is used. - with this RC : the ${version} is replaced with the current pom.version. It's not a blocking issue because we can easily replace with : subject.. - ${releaseVersion} ../subject and use mvn blabla -DreleaseVersion= But I hope there is no other side effect. -- Olivier 2008/3/26, Brian E. Fox [EMAIL PROTECTED]: We fixed the regressions identified last week with the plugin tools and reporting impl. The new 2.0.9 is staged at http://people.apache.org/~brianf/staging-repository/org/apache/ maven/apa che-maven/2.0.9-RC3/ You'll notice that this one has an RC qualifier attached to it. Since what I've actually been staging hasn't been for an official vote, it makes more sense to have actual deterministic numbers on them instead of continuously rolling back and forth between .10 and .9. The other significant reason it has a qualifier is that I want to solicit feedback from the users list without potentially getting multiple versions out there called 2.0.9. My new mantra for the maven release is no more regressions. To that end, what I intend to do is let the RC sit here for a day. If no one turns up anything new (it should be good since this is really attempt #3), then I'll email the user list to solicit feedback. Naturally we'll probably get a slew of can you fix xyz but the only thing that we will consider at this point would be a regression from 2.0.8 to the current RC. If something is identified then we should consider fixing it and re-releasing RC4. I think that having the users more involved in testing the RCs is the only way to really identify and eliminate regressions. If someone identifies a regression after the fact and didn't speak up or try it, well that's unfortunate but it'll have to wait. The RC can sit with the users for 3 days. If nothing turns up, then I'll restage with a final release tag and we can do a formal vote. Assuming this is all successful, then I'll document a more formal Core release procedure that we can follow going forward. Here's the list of issues fixed in the latest RC: Release Notes - Maven 2 - Version 2.0.9 ** Bug * [MNG-1412] - dependency sorting in classpath * [MNG-1914] - Wrong url in error message when using a mirror * [MNG-2123] - NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range * [MNG-2145] - Plugins' dependencies are not always checked * [MNG-2178] - incorrect M2_HOME guess in mvn.bat * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when profiles section is missing or empty * [MNG-2339] - ${project.*} are interpreted in the wrong place * [MNG-2744] - checksum comparison should be case-insensitive * [MNG-2809] - Can't activate a profile by checking for the presence of a file in ${user.home} * [MNG-2848] - Environment variables in profile activation not working * [MNG-2861] - NullPointerException in DefaultArtifactCollector for relocated resolvedArtifacts with different version ranges and available versions. * [MNG-2925] - NullPointerException in PluginDescriptor.getMojo() if there's no mojo in pom.xml * [MNG-2928] - Null pointer exeception when introducing version range [major.minor.build-SNAPSHOT,) * [MNG-2972] - Ignores version of plugin dependency specified in my pom * [MNG-3086] - NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136) * [MNG-3099] - Profiles ignored when working with non-projects (such as archetype:create) * [MNG-3111] - Classpath order incorrect * [MNG-3156] - NullPointerException with mvn dependency:sources * [MNG-3221] - Infinite loop in DefaultLifecycleExecutor * [MNG-3259] - Regression: Maven
CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
BTW, I found this comment on line 981 of DefaultMavenProjectBuilder: // [MNG-2339] ensure the system properties are still interpolated for backwards compat, but the model values must win I've checked that issue, and it looks like it was closed for this release...so, not present in 2.0.8. Additionally, the doesn't seem to say anything about which is supposed to win - model vs. sysprops. IMO, it makes more sense for CLI properties to override those in the model, since it follows the principle of local-most wins that we employ in other parts of Maven, but I'm not sure I know enough about the history of this issue. Does anyone have another issue number that contributes more to this discussion, that we could use to determine the correct course of action here? Thanks, -john On Mar 27, 2008, at 12:54 PM, John Casey wrote: Hmm, I'll have to do some homework on this one, but yeah, it looks like the interpolation changes I put in to get the path-translation in place. I'll have to see if I can work up a test case for this, and try to track down that original issue. Let me get to work on it and I'll see how fast I can come up with something. -john On Mar 27, 2008, at 8:09 AM, Brian E. Fox wrote: Hrm. It's probably a good idea to use a different property, but we should understand why this changed before going further. John, any ideas? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Lamy Sent: Thursday, March 27, 2008 6:56 AM To: Maven Developers List Subject: Re: [pre vote take 3] 2.0.9-RC3 Hi, Testing on corporate projects and build fine. +1 I have just noticed a change (regression ?). We have a corporate plugin. In the pom it's configured as this : plugin .. configuration subject.. - ${version} ../subject We use it with mvn blabla -Dversion=here a version. The value has changed : - with mvn 2.0.8 : the value from the cli is used. - with this RC : the ${version} is replaced with the current pom.version. It's not a blocking issue because we can easily replace with : subject.. - ${releaseVersion} ../subject and use mvn blabla -DreleaseVersion= But I hope there is no other side effect. -- Olivier 2008/3/26, Brian E. Fox [EMAIL PROTECTED]: We fixed the regressions identified last week with the plugin tools and reporting impl. The new 2.0.9 is staged at http://people.apache.org/~brianf/staging-repository/org/apache/ maven/apa che-maven/2.0.9-RC3/ You'll notice that this one has an RC qualifier attached to it. Since what I've actually been staging hasn't been for an official vote, it makes more sense to have actual deterministic numbers on them instead of continuously rolling back and forth between .10 and .9. The other significant reason it has a qualifier is that I want to solicit feedback from the users list without potentially getting multiple versions out there called 2.0.9. My new mantra for the maven release is no more regressions. To that end, what I intend to do is let the RC sit here for a day. If no one turns up anything new (it should be good since this is really attempt #3), then I'll email the user list to solicit feedback. Naturally we'll probably get a slew of can you fix xyz but the only thing that we will consider at this point would be a regression from 2.0.8 to the current RC. If something is identified then we should consider fixing it and re-releasing RC4. I think that having the users more involved in testing the RCs is the only way to really identify and eliminate regressions. If someone identifies a regression after the fact and didn't speak up or try it, well that's unfortunate but it'll have to wait. The RC can sit with the users for 3 days. If nothing turns up, then I'll restage with a final release tag and we can do a formal vote. Assuming this is all successful, then I'll document a more formal Core release procedure that we can follow going forward. Here's the list of issues fixed in the latest RC: Release Notes - Maven 2 - Version 2.0.9 ** Bug * [MNG-1412] - dependency sorting in classpath * [MNG-1914] - Wrong url in error message when using a mirror * [MNG-2123] - NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range * [MNG-2145] - Plugins' dependencies are not always checked * [MNG-2178] - incorrect M2_HOME guess in mvn.bat * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when profiles section is missing or empty * [MNG-2339] - ${project.*} are interpreted in the wrong place * [MNG-2744] - checksum comparison should be case-insensitive * [MNG-2809] - Can't activate a profile by checking for the presence of a file in ${user.home} * [MNG-2848] - Environment variables in profile activation not
Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
Sorry for the spam. Digging deeper through the related links on MNG-2339, it's apparent that the comment in the DefaultMavenProjectBuilder is a touch misleading. The key issues relevant to where sysprops get used during interpolation are: MNG-2745 MNG-2651 It seems that environments that use maven programmatically (in 2.0.x? really??) are running into collisions where other libraries are injecting system properties that override values from the POM for the purposes of interpolation. For this reason (and because we don't have a concept of CLI properties separate from sysprops yet), the code in the project builder was changed to prefer values from the POM over sysprops. -john On Mar 27, 2008, at 1:06 PM, John Casey wrote: BTW, I found this comment on line 981 of DefaultMavenProjectBuilder: // [MNG-2339] ensure the system properties are still interpolated for backwards compat, but the model values must win I've checked that issue, and it looks like it was closed for this release...so, not present in 2.0.8. Additionally, the doesn't seem to say anything about which is supposed to win - model vs. sysprops. IMO, it makes more sense for CLI properties to override those in the model, since it follows the principle of local-most wins that we employ in other parts of Maven, but I'm not sure I know enough about the history of this issue. Does anyone have another issue number that contributes more to this discussion, that we could use to determine the correct course of action here? Thanks, -john On Mar 27, 2008, at 12:54 PM, John Casey wrote: Hmm, I'll have to do some homework on this one, but yeah, it looks like the interpolation changes I put in to get the path- translation in place. I'll have to see if I can work up a test case for this, and try to track down that original issue. Let me get to work on it and I'll see how fast I can come up with something. -john On Mar 27, 2008, at 8:09 AM, Brian E. Fox wrote: Hrm. It's probably a good idea to use a different property, but we should understand why this changed before going further. John, any ideas? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Lamy Sent: Thursday, March 27, 2008 6:56 AM To: Maven Developers List Subject: Re: [pre vote take 3] 2.0.9-RC3 Hi, Testing on corporate projects and build fine. +1 I have just noticed a change (regression ?). We have a corporate plugin. In the pom it's configured as this : plugin .. configuration subject.. - ${version} ../subject We use it with mvn blabla -Dversion=here a version. The value has changed : - with mvn 2.0.8 : the value from the cli is used. - with this RC : the ${version} is replaced with the current pom.version. It's not a blocking issue because we can easily replace with : subject.. - ${releaseVersion} ../subject and use mvn blabla -DreleaseVersion= But I hope there is no other side effect. -- Olivier 2008/3/26, Brian E. Fox [EMAIL PROTECTED]: We fixed the regressions identified last week with the plugin tools and reporting impl. The new 2.0.9 is staged at http://people.apache.org/~brianf/staging-repository/org/apache/ maven/apa che-maven/2.0.9-RC3/ You'll notice that this one has an RC qualifier attached to it. Since what I've actually been staging hasn't been for an official vote, it makes more sense to have actual deterministic numbers on them instead of continuously rolling back and forth between .10 and .9. The other significant reason it has a qualifier is that I want to solicit feedback from the users list without potentially getting multiple versions out there called 2.0.9. My new mantra for the maven release is no more regressions. To that end, what I intend to do is let the RC sit here for a day. If no one turns up anything new (it should be good since this is really attempt #3), then I'll email the user list to solicit feedback. Naturally we'll probably get a slew of can you fix xyz but the only thing that we will consider at this point would be a regression from 2.0.8 to the current RC. If something is identified then we should consider fixing it and re-releasing RC4. I think that having the users more involved in testing the RCs is the only way to really identify and eliminate regressions. If someone identifies a regression after the fact and didn't speak up or try it, well that's unfortunate but it'll have to wait. The RC can sit with the users for 3 days. If nothing turns up, then I'll restage with a final release tag and we can do a formal vote. Assuming this is all successful, then I'll document a more formal Core release procedure that we can follow going forward. Here's the list of issues fixed in the latest RC: Release Notes - Maven 2 - Version 2.0.9 ** Bug * [MNG-1412] - dependency sorting in
RE: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
CLI should win. There was an issue open that I wrote for that a while ago. I think it's still open even. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 1:07 PM To: Maven Developers List Subject: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3) BTW, I found this comment on line 981 of DefaultMavenProjectBuilder: // [MNG-2339] ensure the system properties are still interpolated for backwards compat, but the model values must win I've checked that issue, and it looks like it was closed for this release...so, not present in 2.0.8. Additionally, the doesn't seem to say anything about which is supposed to win - model vs. sysprops. IMO, it makes more sense for CLI properties to override those in the model, since it follows the principle of local-most wins that we employ in other parts of Maven, but I'm not sure I know enough about the history of this issue. Does anyone have another issue number that contributes more to this discussion, that we could use to determine the correct course of action here? Thanks, -john On Mar 27, 2008, at 12:54 PM, John Casey wrote: Hmm, I'll have to do some homework on this one, but yeah, it looks like the interpolation changes I put in to get the path-translation in place. I'll have to see if I can work up a test case for this, and try to track down that original issue. Let me get to work on it and I'll see how fast I can come up with something. -john On Mar 27, 2008, at 8:09 AM, Brian E. Fox wrote: Hrm. It's probably a good idea to use a different property, but we should understand why this changed before going further. John, any ideas? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Lamy Sent: Thursday, March 27, 2008 6:56 AM To: Maven Developers List Subject: Re: [pre vote take 3] 2.0.9-RC3 Hi, Testing on corporate projects and build fine. +1 I have just noticed a change (regression ?). We have a corporate plugin. In the pom it's configured as this : plugin .. configuration subject.. - ${version} ../subject We use it with mvn blabla -Dversion=here a version. The value has changed : - with mvn 2.0.8 : the value from the cli is used. - with this RC : the ${version} is replaced with the current pom.version. It's not a blocking issue because we can easily replace with : subject.. - ${releaseVersion} ../subject and use mvn blabla -DreleaseVersion= But I hope there is no other side effect. -- Olivier 2008/3/26, Brian E. Fox [EMAIL PROTECTED]: We fixed the regressions identified last week with the plugin tools and reporting impl. The new 2.0.9 is staged at http://people.apache.org/~brianf/staging-repository/org/apache/ maven/apa che-maven/2.0.9-RC3/ You'll notice that this one has an RC qualifier attached to it. Since what I've actually been staging hasn't been for an official vote, it makes more sense to have actual deterministic numbers on them instead of continuously rolling back and forth between .10 and .9. The other significant reason it has a qualifier is that I want to solicit feedback from the users list without potentially getting multiple versions out there called 2.0.9. My new mantra for the maven release is no more regressions. To that end, what I intend to do is let the RC sit here for a day. If no one turns up anything new (it should be good since this is really attempt #3), then I'll email the user list to solicit feedback. Naturally we'll probably get a slew of can you fix xyz but the only thing that we will consider at this point would be a regression from 2.0.8 to the current RC. If something is identified then we should consider fixing it and re-releasing RC4. I think that having the users more involved in testing the RCs is the only way to really identify and eliminate regressions. If someone identifies a regression after the fact and didn't speak up or try it, well that's unfortunate but it'll have to wait. The RC can sit with the users for 3 days. If nothing turns up, then I'll restage with a final release tag and we can do a formal vote. Assuming this is all successful, then I'll document a more formal Core release procedure that we can follow going forward. Here's the list of issues fixed in the latest RC: Release Notes - Maven 2 - Version 2.0.9 ** Bug * [MNG-1412] - dependency sorting in classpath * [MNG-1914] - Wrong url in error message when using a mirror * [MNG-2123] - NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range * [MNG-2145] - Plugins' dependencies are not always checked * [MNG-2178] - incorrect M2_HOME guess in mvn.bat * [MNG-2234] -
RE: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
We have to err on the side of not causing more regressions. If we want to move in this direction, we should start deprecating the non ${project. Forms of the properties with big warnings in 2.0.9. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 1:16 PM To: Maven Developers List Subject: Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3) Sorry for the spam. Digging deeper through the related links on MNG-2339, it's apparent that the comment in the DefaultMavenProjectBuilder is a touch misleading. The key issues relevant to where sysprops get used during interpolation are: MNG-2745 MNG-2651 It seems that environments that use maven programmatically (in 2.0.x? really??) are running into collisions where other libraries are injecting system properties that override values from the POM for the purposes of interpolation. For this reason (and because we don't have a concept of CLI properties separate from sysprops yet), the code in the project builder was changed to prefer values from the POM over sysprops. -john On Mar 27, 2008, at 1:06 PM, John Casey wrote: BTW, I found this comment on line 981 of DefaultMavenProjectBuilder: // [MNG-2339] ensure the system properties are still interpolated for backwards compat, but the model values must win I've checked that issue, and it looks like it was closed for this release...so, not present in 2.0.8. Additionally, the doesn't seem to say anything about which is supposed to win - model vs. sysprops. IMO, it makes more sense for CLI properties to override those in the model, since it follows the principle of local-most wins that we employ in other parts of Maven, but I'm not sure I know enough about the history of this issue. Does anyone have another issue number that contributes more to this discussion, that we could use to determine the correct course of action here? Thanks, -john On Mar 27, 2008, at 12:54 PM, John Casey wrote: Hmm, I'll have to do some homework on this one, but yeah, it looks like the interpolation changes I put in to get the path- translation in place. I'll have to see if I can work up a test case for this, and try to track down that original issue. Let me get to work on it and I'll see how fast I can come up with something. -john On Mar 27, 2008, at 8:09 AM, Brian E. Fox wrote: Hrm. It's probably a good idea to use a different property, but we should understand why this changed before going further. John, any ideas? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Lamy Sent: Thursday, March 27, 2008 6:56 AM To: Maven Developers List Subject: Re: [pre vote take 3] 2.0.9-RC3 Hi, Testing on corporate projects and build fine. +1 I have just noticed a change (regression ?). We have a corporate plugin. In the pom it's configured as this : plugin .. configuration subject.. - ${version} ../subject We use it with mvn blabla -Dversion=here a version. The value has changed : - with mvn 2.0.8 : the value from the cli is used. - with this RC : the ${version} is replaced with the current pom.version. It's not a blocking issue because we can easily replace with : subject.. - ${releaseVersion} ../subject and use mvn blabla -DreleaseVersion= But I hope there is no other side effect. -- Olivier 2008/3/26, Brian E. Fox [EMAIL PROTECTED]: We fixed the regressions identified last week with the plugin tools and reporting impl. The new 2.0.9 is staged at http://people.apache.org/~brianf/staging-repository/org/apache/ maven/apa che-maven/2.0.9-RC3/ You'll notice that this one has an RC qualifier attached to it. Since what I've actually been staging hasn't been for an official vote, it makes more sense to have actual deterministic numbers on them instead of continuously rolling back and forth between .10 and .9. The other significant reason it has a qualifier is that I want to solicit feedback from the users list without potentially getting multiple versions out there called 2.0.9. My new mantra for the maven release is no more regressions. To that end, what I intend to do is let the RC sit here for a day. If no one turns up anything new (it should be good since this is really attempt #3), then I'll email the user list to solicit feedback. Naturally we'll probably get a slew of can you fix xyz but the only thing that we will consider at this point would be a regression from 2.0.8 to the current RC. If something is identified then we should consider fixing it and re-releasing RC4. I think that having the users more involved in testing the RCs is the only way to really identify and eliminate regressions. If someone identifies a regression after the fact and didn't speak up
Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
I was incorrect; this is not a result of code I changed. I'll have to take a look at the SVN annotation to find the commit that changed this, but it looks like it may have been part of some work Jason was doing. I'm looking into it now. -john On Mar 27, 2008, at 1:19 PM, Brian E. Fox wrote: We have to err on the side of not causing more regressions. If we want to move in this direction, we should start deprecating the non ${project. Forms of the properties with big warnings in 2.0.9. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 1:16 PM To: Maven Developers List Subject: Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3) Sorry for the spam. Digging deeper through the related links on MNG-2339, it's apparent that the comment in the DefaultMavenProjectBuilder is a touch misleading. The key issues relevant to where sysprops get used during interpolation are: MNG-2745 MNG-2651 It seems that environments that use maven programmatically (in 2.0.x? really??) are running into collisions where other libraries are injecting system properties that override values from the POM for the purposes of interpolation. For this reason (and because we don't have a concept of CLI properties separate from sysprops yet), the code in the project builder was changed to prefer values from the POM over sysprops. -john On Mar 27, 2008, at 1:06 PM, John Casey wrote: BTW, I found this comment on line 981 of DefaultMavenProjectBuilder: // [MNG-2339] ensure the system properties are still interpolated for backwards compat, but the model values must win I've checked that issue, and it looks like it was closed for this release...so, not present in 2.0.8. Additionally, the doesn't seem to say anything about which is supposed to win - model vs. sysprops. IMO, it makes more sense for CLI properties to override those in the model, since it follows the principle of local-most wins that we employ in other parts of Maven, but I'm not sure I know enough about the history of this issue. Does anyone have another issue number that contributes more to this discussion, that we could use to determine the correct course of action here? Thanks, -john On Mar 27, 2008, at 12:54 PM, John Casey wrote: Hmm, I'll have to do some homework on this one, but yeah, it looks like the interpolation changes I put in to get the path- translation in place. I'll have to see if I can work up a test case for this, and try to track down that original issue. Let me get to work on it and I'll see how fast I can come up with something. -john On Mar 27, 2008, at 8:09 AM, Brian E. Fox wrote: Hrm. It's probably a good idea to use a different property, but we should understand why this changed before going further. John, any ideas? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Lamy Sent: Thursday, March 27, 2008 6:56 AM To: Maven Developers List Subject: Re: [pre vote take 3] 2.0.9-RC3 Hi, Testing on corporate projects and build fine. +1 I have just noticed a change (regression ?). We have a corporate plugin. In the pom it's configured as this : plugin .. configuration subject.. - ${version} ../subject We use it with mvn blabla -Dversion=here a version. The value has changed : - with mvn 2.0.8 : the value from the cli is used. - with this RC : the ${version} is replaced with the current pom.version. It's not a blocking issue because we can easily replace with : subject.. - ${releaseVersion} ../subject and use mvn blabla -DreleaseVersion= But I hope there is no other side effect. -- Olivier 2008/3/26, Brian E. Fox [EMAIL PROTECTED]: We fixed the regressions identified last week with the plugin tools and reporting impl. The new 2.0.9 is staged at http://people.apache.org/~brianf/staging-repository/org/apache/ maven/apa che-maven/2.0.9-RC3/ You'll notice that this one has an RC qualifier attached to it. Since what I've actually been staging hasn't been for an official vote, it makes more sense to have actual deterministic numbers on them instead of continuously rolling back and forth between .10 and .9. The other significant reason it has a qualifier is that I want to solicit feedback from the users list without potentially getting multiple versions out there called 2.0.9. My new mantra for the maven release is no more regressions. To that end, what I intend to do is let the RC sit here for a day. If no one turns up anything new (it should be good since this is really attempt #3), then I'll email the user list to solicit feedback. Naturally we'll probably get a slew of can you fix xyz but the only thing that we will consider at this point would be a regression from 2.0.8 to the current RC. If something is identified then we should consider fixing it and re-releasing RC4. I think that having the users
Re: [pre vote take 3] 2.0.9-RC3
I'm seeing a regression in CXF builds with 2.0.9-RC3. I cannot do a deploy. One of the CXF poms is probably not setup completely optimal, but it works for 2.0.6-2.0.8. Basically, for some reason, it ends up running javadoc twice. With 2.0.8, that's fine. With 2.0.9, I get: [INFO] Building jar: /home/dkulp/working/cxf/api/target/cxf-api-2.1-incubator-SNAPSHOT-javadoc.jar [WARNING] Duplicate artifact attachment detected. (project: org.apache.cxf:cxf-api:jar:2.1-incubator-SNAPSHOT; illegal attachment: org.apache.cxf:cxf-api:javadoc:javadoc:2.1-incubator-SNAPSHOT) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error attaching artifact to project: Duplicate attachment. Embedded error: Duplicate artifact attachment detected. (project: org.apache.cxf:cxf-api:jar:2.1-incubator-SNAPSHOT; illegal attachment: org.apache.cxf:cxf-api:javadoc:javadoc:2.1-incubator-SNAPSHOT) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] Dan Brian E Fox wrote: We fixed the regressions identified last week with the plugin tools and reporting impl. The new 2.0.9 is staged at http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa che-maven/2.0.9-RC3/ You'll notice that this one has an RC qualifier attached to it. Since what I've actually been staging hasn't been for an official vote, it makes more sense to have actual deterministic numbers on them instead of continuously rolling back and forth between .10 and .9. The other significant reason it has a qualifier is that I want to solicit feedback from the users list without potentially getting multiple versions out there called 2.0.9. My new mantra for the maven release is no more regressions. To that end, what I intend to do is let the RC sit here for a day. If no one turns up anything new (it should be good since this is really attempt #3), then I'll email the user list to solicit feedback. Naturally we'll probably get a slew of can you fix xyz but the only thing that we will consider at this point would be a regression from 2.0.8 to the current RC. If something is identified then we should consider fixing it and re-releasing RC4. I think that having the users more involved in testing the RCs is the only way to really identify and eliminate regressions. If someone identifies a regression after the fact and didn't speak up or try it, well that's unfortunate but it'll have to wait. The RC can sit with the users for 3 days. If nothing turns up, then I'll restage with a final release tag and we can do a formal vote. Assuming this is all successful, then I'll document a more formal Core release procedure that we can follow going forward. Here's the list of issues fixed in the latest RC: Release Notes - Maven 2 - Version 2.0.9 ** Bug * [MNG-1412] - dependency sorting in classpath * [MNG-1914] - Wrong url in error message when using a mirror * [MNG-2123] - NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range * [MNG-2145] - Plugins' dependencies are not always checked * [MNG-2178] - incorrect M2_HOME guess in mvn.bat * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when profiles section is missing or empty * [MNG-2339] - ${project.*} are interpreted in the wrong place * [MNG-2744] - checksum comparison should be case-insensitive * [MNG-2809] - Can't activate a profile by checking for the presence of a file in ${user.home} * [MNG-2848] - Environment variables in profile activation not working * [MNG-2861] - NullPointerException in DefaultArtifactCollector for relocated resolvedArtifacts with different version ranges and available versions. * [MNG-2925] - NullPointerException in PluginDescriptor.getMojo() if there's no mojo in pom.xml * [MNG-2928] - Null pointer exeception when introducing version range [major.minor.build-SNAPSHOT,) * [MNG-2972] - Ignores version of plugin dependency specified in my pom * [MNG-3086] - NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136) * [MNG-3099] - Profiles ignored when working with non-projects (such as archetype:create) * [MNG-3111] - Classpath order incorrect * [MNG-3156] - NullPointerException with mvn dependency:sources * [MNG-3221] - Infinite loop in DefaultLifecycleExecutor * [MNG-3259] - Regression: Maven drops dependencies in multi-module build * [MNG-3286] - execution.inherited field is ignored * [MNG-3288] - Invalid systemPath allows build to continue--failing in
Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
I changed it, and it was in http://jira.codehaus.org/browse/MNG-2339 as the comment says. JDK 1.4 defines a system property for version that is 2.4.1 for some reason, and it wreaks havoc on anything that uses ${version}, $ {project.version}, etc. I can't see why overriding model values makes any sense from the command line - that's not what Olivier wanted but rather a straight substitution. The only change I can think of here is to have previous behaviour from ${version} and make sure ${project.version} is unaffected, but that's a significant change to the interpolator. I think we're better off leaving this fix in with something in the release notes. - Brett On 28/03/2008, at 4:49 AM, John Casey wrote: I was incorrect; this is not a result of code I changed. I'll have to take a look at the SVN annotation to find the commit that changed this, but it looks like it may have been part of some work Jason was doing. I'm looking into it now. -john On Mar 27, 2008, at 1:19 PM, Brian E. Fox wrote: We have to err on the side of not causing more regressions. If we want to move in this direction, we should start deprecating the non ${project. Forms of the properties with big warnings in 2.0.9. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 1:16 PM To: Maven Developers List Subject: Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3) Sorry for the spam. Digging deeper through the related links on MNG-2339, it's apparent that the comment in the DefaultMavenProjectBuilder is a touch misleading. The key issues relevant to where sysprops get used during interpolation are: MNG-2745 MNG-2651 It seems that environments that use maven programmatically (in 2.0.x? really??) are running into collisions where other libraries are injecting system properties that override values from the POM for the purposes of interpolation. For this reason (and because we don't have a concept of CLI properties separate from sysprops yet), the code in the project builder was changed to prefer values from the POM over sysprops. -john On Mar 27, 2008, at 1:06 PM, John Casey wrote: BTW, I found this comment on line 981 of DefaultMavenProjectBuilder: // [MNG-2339] ensure the system properties are still interpolated for backwards compat, but the model values must win I've checked that issue, and it looks like it was closed for this release...so, not present in 2.0.8. Additionally, the doesn't seem to say anything about which is supposed to win - model vs. sysprops. IMO, it makes more sense for CLI properties to override those in the model, since it follows the principle of local-most wins that we employ in other parts of Maven, but I'm not sure I know enough about the history of this issue. Does anyone have another issue number that contributes more to this discussion, that we could use to determine the correct course of action here? Thanks, -john On Mar 27, 2008, at 12:54 PM, John Casey wrote: Hmm, I'll have to do some homework on this one, but yeah, it looks like the interpolation changes I put in to get the path- translation in place. I'll have to see if I can work up a test case for this, and try to track down that original issue. Let me get to work on it and I'll see how fast I can come up with something. -john On Mar 27, 2008, at 8:09 AM, Brian E. Fox wrote: Hrm. It's probably a good idea to use a different property, but we should understand why this changed before going further. John, any ideas? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Lamy Sent: Thursday, March 27, 2008 6:56 AM To: Maven Developers List Subject: Re: [pre vote take 3] 2.0.9-RC3 Hi, Testing on corporate projects and build fine. +1 I have just noticed a change (regression ?). We have a corporate plugin. In the pom it's configured as this : plugin .. configuration subject.. - ${version} ../subject We use it with mvn blabla -Dversion=here a version. The value has changed : - with mvn 2.0.8 : the value from the cli is used. - with this RC : the ${version} is replaced with the current pom.version. It's not a blocking issue because we can easily replace with : subject.. - ${releaseVersion} ../subject and use mvn blabla -DreleaseVersion= But I hope there is no other side effect. -- Olivier 2008/3/26, Brian E. Fox [EMAIL PROTECTED]: We fixed the regressions identified last week with the plugin tools and reporting impl. The new 2.0.9 is staged at http://people.apache.org/~brianf/staging-repository/org/apache/ maven/apa che-maven/2.0.9-RC3/ You'll notice that this one has an RC qualifier attached to it. Since what I've actually been staging hasn't been for an official vote, it makes more sense to have actual deterministic numbers on them instead of continuously rolling back and forth between .10 and .9. The
RE: [pre vote take 3] 2.0.9-RC3
Hi Dan, we saw that last night, try the RC4-SNAPSHOT: http://people.apache.org/~brianf -Original Message- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 2:54 PM To: dev@maven.apache.org Subject: Re: [pre vote take 3] 2.0.9-RC3 I'm seeing a regression in CXF builds with 2.0.9-RC3. I cannot do a deploy. One of the CXF poms is probably not setup completely optimal, but it works for 2.0.6-2.0.8. Basically, for some reason, it ends up running javadoc twice. With 2.0.8, that's fine. With 2.0.9, I get: [INFO] Building jar: /home/dkulp/working/cxf/api/target/cxf-api-2.1-incubator-SNAPSHOT-javado c.jar [WARNING] Duplicate artifact attachment detected. (project: org.apache.cxf:cxf-api:jar:2.1-incubator-SNAPSHOT; illegal attachment: org.apache.cxf:cxf-api:javadoc:javadoc:2.1-incubator-SNAPSHOT) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error attaching artifact to project: Duplicate attachment. Embedded error: Duplicate artifact attachment detected. (project: org.apache.cxf:cxf-api:jar:2.1-incubator-SNAPSHOT; illegal attachment: org.apache.cxf:cxf-api:javadoc:javadoc:2.1-incubator-SNAPSHOT) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] Dan Brian E Fox wrote: We fixed the regressions identified last week with the plugin tools and reporting impl. The new 2.0.9 is staged at http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa che-maven/2.0.9-RC3/ You'll notice that this one has an RC qualifier attached to it. Since what I've actually been staging hasn't been for an official vote, it makes more sense to have actual deterministic numbers on them instead of continuously rolling back and forth between .10 and .9. The other significant reason it has a qualifier is that I want to solicit feedback from the users list without potentially getting multiple versions out there called 2.0.9. My new mantra for the maven release is no more regressions. To that end, what I intend to do is let the RC sit here for a day. If no one turns up anything new (it should be good since this is really attempt #3), then I'll email the user list to solicit feedback. Naturally we'll probably get a slew of can you fix xyz but the only thing that we will consider at this point would be a regression from 2.0.8 to the current RC. If something is identified then we should consider fixing it and re-releasing RC4. I think that having the users more involved in testing the RCs is the only way to really identify and eliminate regressions. If someone identifies a regression after the fact and didn't speak up or try it, well that's unfortunate but it'll have to wait. The RC can sit with the users for 3 days. If nothing turns up, then I'll restage with a final release tag and we can do a formal vote. Assuming this is all successful, then I'll document a more formal Core release procedure that we can follow going forward. Here's the list of issues fixed in the latest RC: Release Notes - Maven 2 - Version 2.0.9 ** Bug * [MNG-1412] - dependency sorting in classpath * [MNG-1914] - Wrong url in error message when using a mirror * [MNG-2123] - NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range * [MNG-2145] - Plugins' dependencies are not always checked * [MNG-2178] - incorrect M2_HOME guess in mvn.bat * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when profiles section is missing or empty * [MNG-2339] - ${project.*} are interpreted in the wrong place * [MNG-2744] - checksum comparison should be case-insensitive * [MNG-2809] - Can't activate a profile by checking for the presence of a file in ${user.home} * [MNG-2848] - Environment variables in profile activation not working * [MNG-2861] - NullPointerException in DefaultArtifactCollector for relocated resolvedArtifacts with different version ranges and available versions. * [MNG-2925] - NullPointerException in PluginDescriptor.getMojo() if there's no mojo in pom.xml * [MNG-2928] - Null pointer exeception when introducing version range [major.minor.build-SNAPSHOT,) * [MNG-2972] - Ignores version of plugin dependency specified in my pom * [MNG-3086] - NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136) * [MNG-3099] - Profiles ignored when working with non-projects (such as archetype:create) * [MNG-3111] - Classpath order incorrect * [MNG-3156] - NullPointerException with mvn dependency:sources *
RE: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
I can't see why overriding model values makes any sense from the command line - that's not what Olivier wanted but rather a straight substitution. You shouldn't be able to override model values for sure. I was saying that if something is defined on the CLI for everything else, it should take precedence. The only change I can think of here is to have previous behaviour from ${version} and make sure ${project.version} is unaffected, but that's a significant change to the interpolator. That's not promising. I think we're better off leaving this fix in with something in the release notes. I don't. We need to stop shoving incompatible changes down the user's throats. It shouldn't always require reworking of your poms to upgrade to the next maven version. That's annoying and wrong. If we do need to make changes, and I agree that forward progress must be made that sometimes breaks stuff, it should be deprecated first so people can get a chance to fix their poms. Based on the votes and comments in the issue, it's clear we can't just revert it either...We need to fix this correctly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
Brian, what do you consider the correct fix? That CLI takes precedence over POM properties? I was trying to glean through this chain to find out your proposal. Paul On Thu, Mar 27, 2008 at 2:08 PM, Brian E. Fox [EMAIL PROTECTED] wrote: I can't see why overriding model values makes any sense from the command line - that's not what Olivier wanted but rather a straight substitution. You shouldn't be able to override model values for sure. I was saying that if something is defined on the CLI for everything else, it should take precedence. The only change I can think of here is to have previous behaviour from ${version} and make sure ${project.version} is unaffected, but that's a significant change to the interpolator. That's not promising. I think we're better off leaving this fix in with something in the release notes. I don't. We need to stop shoving incompatible changes down the user's throats. It shouldn't always require reworking of your poms to upgrade to the next maven version. That's annoying and wrong. If we do need to make changes, and I agree that forward progress must be made that sometimes breaks stuff, it should be deprecated first so people can get a chance to fix their poms. Based on the votes and comments in the issue, it's clear we can't just revert it either...We need to fix this correctly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
On 28/03/2008, at 6:37 AM, Paul Benedict wrote: Brian, what do you consider the correct fix? That CLI takes precedence over POM properties? I was trying to glean through this chain to find out your proposal. The most correct fix is: a) -Dversion should still replace ${version} b) -Dversion should not replace ${project.version} c) ${version} should evaluate to ${project.version} if nothing else specified (though this should be deprecated behaviour). The same applies for every other pom property, not just version. The problem with my fix is that (a) no longer holds, though reverting would sacrifice (b). On IRC, John said he has a potential fix that makes (a) hold, and while (b) doesn't, it mitigates the main observed side effect which is -Dversion coming in from the environment, rather than the command line. This is the least risk, but it's also another new behaviour we may not want to preserve. Fixing (a) + (b) is possible, but also risks some other regression in (c). - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
We're actively discussing on IRC, but in my mind a correct fix is one that fixes the root of the jira, which is that system properties where hosing versions, and doesn't break more builds. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Benedict Sent: Thursday, March 27, 2008 3:38 PM To: Maven Developers List Subject: Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3) Brian, what do you consider the correct fix? That CLI takes precedence over POM properties? I was trying to glean through this chain to find out your proposal. Paul On Thu, Mar 27, 2008 at 2:08 PM, Brian E. Fox [EMAIL PROTECTED] wrote: I can't see why overriding model values makes any sense from the command line - that's not what Olivier wanted but rather a straight substitution. You shouldn't be able to override model values for sure. I was saying that if something is defined on the CLI for everything else, it should take precedence. The only change I can think of here is to have previous behaviour from ${version} and make sure ${project.version} is unaffected, but that's a significant change to the interpolator. That's not promising. I think we're better off leaving this fix in with something in the release notes. I don't. We need to stop shoving incompatible changes down the user's throats. It shouldn't always require reworking of your poms to upgrade to the next maven version. That's annoying and wrong. If we do need to make changes, and I agree that forward progress must be made that sometimes breaks stuff, it should be deprecated first so people can get a chance to fix their poms. Based on the votes and comments in the issue, it's clear we can't just revert it either...We need to fix this correctly. - 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]
Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
There should be absolutely no system properties manipulation in the bowels of Maven. Or envars, they both need to be trapped at the front- end because we end up with little bits here and there. They should all be grabbed from the CLI, the order of precedence determined and then passed into Maven as properties. All the system properties and envar need to be entirely contained to the CLI. That's the direction I've been moving in. Even if we obey things like ${ENV.foo} that should be a property not operating on envars directly in the core. On 27-Mar-08, at 10:49 AM, John Casey wrote: I was incorrect; this is not a result of code I changed. I'll have to take a look at the SVN annotation to find the commit that changed this, but it looks like it may have been part of some work Jason was doing. I'm looking into it now. -john On Mar 27, 2008, at 1:19 PM, Brian E. Fox wrote: We have to err on the side of not causing more regressions. If we want to move in this direction, we should start deprecating the non ${project. Forms of the properties with big warnings in 2.0.9. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 1:16 PM To: Maven Developers List Subject: Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3) Sorry for the spam. Digging deeper through the related links on MNG-2339, it's apparent that the comment in the DefaultMavenProjectBuilder is a touch misleading. The key issues relevant to where sysprops get used during interpolation are: MNG-2745 MNG-2651 It seems that environments that use maven programmatically (in 2.0.x? really??) are running into collisions where other libraries are injecting system properties that override values from the POM for the purposes of interpolation. For this reason (and because we don't have a concept of CLI properties separate from sysprops yet), the code in the project builder was changed to prefer values from the POM over sysprops. -john On Mar 27, 2008, at 1:06 PM, John Casey wrote: BTW, I found this comment on line 981 of DefaultMavenProjectBuilder: // [MNG-2339] ensure the system properties are still interpolated for backwards compat, but the model values must win I've checked that issue, and it looks like it was closed for this release...so, not present in 2.0.8. Additionally, the doesn't seem to say anything about which is supposed to win - model vs. sysprops. IMO, it makes more sense for CLI properties to override those in the model, since it follows the principle of local-most wins that we employ in other parts of Maven, but I'm not sure I know enough about the history of this issue. Does anyone have another issue number that contributes more to this discussion, that we could use to determine the correct course of action here? Thanks, -john On Mar 27, 2008, at 12:54 PM, John Casey wrote: Hmm, I'll have to do some homework on this one, but yeah, it looks like the interpolation changes I put in to get the path- translation in place. I'll have to see if I can work up a test case for this, and try to track down that original issue. Let me get to work on it and I'll see how fast I can come up with something. -john On Mar 27, 2008, at 8:09 AM, Brian E. Fox wrote: Hrm. It's probably a good idea to use a different property, but we should understand why this changed before going further. John, any ideas? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Lamy Sent: Thursday, March 27, 2008 6:56 AM To: Maven Developers List Subject: Re: [pre vote take 3] 2.0.9-RC3 Hi, Testing on corporate projects and build fine. +1 I have just noticed a change (regression ?). We have a corporate plugin. In the pom it's configured as this : plugin .. configuration subject.. - ${version} ../subject We use it with mvn blabla -Dversion=here a version. The value has changed : - with mvn 2.0.8 : the value from the cli is used. - with this RC : the ${version} is replaced with the current pom.version. It's not a blocking issue because we can easily replace with : subject.. - ${releaseVersion} ../subject and use mvn blabla -DreleaseVersion= But I hope there is no other side effect. -- Olivier 2008/3/26, Brian E. Fox [EMAIL PROTECTED]: We fixed the regressions identified last week with the plugin tools and reporting impl. The new 2.0.9 is staged at http://people.apache.org/~brianf/staging-repository/org/apache/ maven/apa che-maven/2.0.9-RC3/ You'll notice that this one has an RC qualifier attached to it. Since what I've actually been staging hasn't been for an official vote, it makes more sense to have actual deterministic numbers on them instead of continuously rolling back and forth between .10 and .9. The other significant reason it has a qualifier is that I want to solicit feedback from the users list without potentially getting multiple
RE: Wagon changes and WebDAV
The other problem with dropping it into the distribution is that when we find out there is a bug in it you can't simply specify a new version of the provider, you would have to go replace the provider and all its deps, or make your own shaded JAR which would be a pain in the ass. (see full thread here: http://www.nabble.com/Wagon-changes-and-WebDAV-td15743343s177.html) So the above captures exactly the problem we are seeing now. James has an issue with webdav that may require a fix. This is probably an existing issue and is not core so it shouldn't hold up the 2.0.9 release. The issue is that even if he finds and fixes it, there's no way to upgrade the extension until we do 2.0.10. This seems like it could be a bigger issue than what we've tried to solve, which is make deploy:deploy-file slightly easier to use for one specific protocol. Reading back over the thread, there seemed to be general consensus that this isn't the direction we wanted to go with the trunk, but that 2.0.x wasn't as much of a concern. I think it should be still a concern given the potential to really lock people in. Furthermore this has a big potential to cause regressions because now we just forced everyone to upgrade their webdav even if they didn't want to...and there's nothing they can do about it. That's not cool and I vote we take this out before minting 2.0.9. (I'm leaving it in for RC4 to allow time for discussion and time for more testing of the RC) --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release Maven Eclipse plugin version 2.5.1
Hi, Since the 2.5 release we did 10 days ago, we solved 3 annoying issues: * [MECLIPSE-266] - plugin applies java facet to ear project * [MECLIPSE-411] - manifest property usage is only for ogsi maifests * [MECLIPSE-413] - EclipseOSGiManifestWriter uses the artifact id and not the EclipseProjectName We also added a new feature : * [MECLIPSE-405] - to-maven target should allow to strip qualifier when creating artifacts from osgi bundles There are still a lot of issues left in JIRA : http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11133status=1 Staging repo : http://people.apache.org/~aheritier/stage/repo/ Staging site (I'm uploading it) : http://maven.apache.org/plugins/maven-eclipse-plugin-2.5.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 5 days. I'll be back on wednesday to do the release if the vote passes. [ ] +1 [ ] +0 [ ] -1 -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pre vote take 3] 2.0.9-RC3
I've been testing the Wagon Webdav module in the current release candidate - there are a few glitches to do with the graceful handling of redirects. See WAGON-103 for more details. I recommend that we should retract this from core for the 2.0.9 release. James On Thu, 2008-03-27 at 11:48 +0100, Fabrice Bellingard wrote: Tested on my projects, works fine. Here's my +1 for RC4. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wagon changes and WebDAV
+1 On Thu, 2008-03-27 at 20:11 -0400, Brian E. Fox wrote: The other problem with dropping it into the distribution is that when we find out there is a bug in it you can't simply specify a new version of the provider, you would have to go replace the provider and all its deps, or make your own shaded JAR which would be a pain in the ass. (see full thread here: http://www.nabble.com/Wagon-changes-and-WebDAV-td15743343s177.html) So the above captures exactly the problem we are seeing now. James has an issue with webdav that may require a fix. This is probably an existing issue and is not core so it shouldn't hold up the 2.0.9 release. The issue is that even if he finds and fixes it, there's no way to upgrade the extension until we do 2.0.10. This seems like it could be a bigger issue than what we've tried to solve, which is make deploy:deploy-file slightly easier to use for one specific protocol. Reading back over the thread, there seemed to be general consensus that this isn't the direction we wanted to go with the trunk, but that 2.0.x wasn't as much of a concern. I think it should be still a concern given the potential to really lock people in. Furthermore this has a big potential to cause regressions because now we just forced everyone to upgrade their webdav even if they didn't want to...and there's nothing they can do about it. That's not cool and I vote we take this out before minting 2.0.9. (I'm leaving it in for RC4 to allow time for discussion and time for more testing of the RC) --Brian - 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]
[2.0.9 RC4]
RC4 corrects the version issue identified by Olivier and the Duplicate artifacts exception identified by several testers. It's staged at: http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa che-maven/2.0.9-RC4/ We'll let this one simmer for a bit while discussion occurs on the webdav issue.
[jira] Subscription: Design Best Practices
Issue Subscription Filter: Design Best Practices (29 issues) Subscriber: mavendevlist Key Summary MNG-2184Possible problem with @aggregator and forked lifecycles http://jira.codehaus.org/browse/MNG-2184 MNG-612 implement conflict resolution techniques http://jira.codehaus.org/browse/MNG-612 MNG-3313NetBeans projects, more than ant project, more than free form project. http://jira.codehaus.org/browse/MNG-3313 MNG-2381improved control over the repositories in the POM http://jira.codehaus.org/browse/MNG-2381 MNG-1950Ability to introduce new lifecycles phases http://jira.codehaus.org/browse/MNG-1950 MNG-2584Rebuild on pom change http://jira.codehaus.org/browse/MNG-2584 MNG-139 server definitions should be reusable - review use of repository IDs http://jira.codehaus.org/browse/MNG-139 MNG-2125[doc] when and how to define plugins in a pom http://jira.codehaus.org/browse/MNG-2125 MNG-474 performance improvement for forked lifecycles http://jira.codehaus.org/browse/MNG-474 MNG-1381best practices: testing strategies http://jira.codehaus.org/browse/MNG-1381 MNG-1931add a reportingManagement section http://jira.codehaus.org/browse/MNG-1931 MNG-1563how to write integration tests http://jira.codehaus.org/browse/MNG-1563 MNG-1423best practices: setting up multi-module build http://jira.codehaus.org/browse/MNG-1423 MNG-1867deprecate system scope, analyse other use cases http://jira.codehaus.org/browse/MNG-1867 MNG-1885Uniquely identify modules by module name and version number http://jira.codehaus.org/browse/MNG-1885 MNG-647 Allow Maven 2 to be monitored using JMX. http://jira.codehaus.org/browse/MNG-647 MNG-868 Use uniform format for properties and other tags http://jira.codehaus.org/browse/MNG-868 MNG-1441Starting thinking about a proper distributed repository mechanism a la CPAN http://jira.codehaus.org/browse/MNG-1441 MNG-416 best practices: multiple profile deployments http://jira.codehaus.org/browse/MNG-416 MNG-657 possible chicken and egg problem with extensions http://jira.codehaus.org/browse/MNG-657 MNG-1440Developer Object Model (DOM) http://jira.codehaus.org/browse/MNG-1440 MNG-1439Organization Object Model (OOM) http://jira.codehaus.org/browse/MNG-1439 MNG-1463best practices: plugin inheritance for a multi project build http://jira.codehaus.org/browse/MNG-1463 MNG-1468best practices: version management in multi project builds http://jira.codehaus.org/browse/MNG-1468 MNG-1425best practices: the location of configuration files vs resources http://jira.codehaus.org/browse/MNG-1425 MNG-367 best practices: multi-user installation http://jira.codehaus.org/browse/MNG-367 MNG-125 guarded mojo execution http://jira.codehaus.org/browse/MNG-125 MNG-1569Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare http://jira.codehaus.org/browse/MNG-1569 MNG-41 best practices: site management http://jira.codehaus.org/browse/MNG-41 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2.0.9 RC4]
Will any tickets be made of these in case they end up regressing (re-opening) in the future? On Thu, Mar 27, 2008 at 8:35 PM, Brian E. Fox [EMAIL PROTECTED] wrote: RC4 corrects the version issue identified by Olivier and the Duplicate artifacts exception identified by several testers. It's staged at: http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa che-maven/2.0.9-RC4/http://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apache-maven/2.0.9-RC4/ We'll let this one simmer for a bit while discussion occurs on the webdav issue.
RE: [2.0.9 RC4]
The work was done under the original tickets, MNG-3119 and MNG-2339. Both of those where caused by fixes in 2.0.9. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Benedict Sent: Thursday, March 27, 2008 11:00 PM To: Maven Developers List Subject: Re: [2.0.9 RC4] Will any tickets be made of these in case they end up regressing (re-opening) in the future? On Thu, Mar 27, 2008 at 8:35 PM, Brian E. Fox [EMAIL PROTECTED] wrote: RC4 corrects the version issue identified by Olivier and the Duplicate artifacts exception identified by several testers. It's staged at: http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa che-maven/2.0.9-RC4/http://people.apache.org/%7Ebrianf/staging-reposito ry/org/apache/maven/apache-maven/2.0.9-RC4/ We'll let this one simmer for a bit while discussion occurs on the webdav issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]