[RESULT] [VOTE] Apache Maven 3.0.4
Hello, The vote has passed with the following result: +1 (binding): John Casey, Emmanuel Venisse, Benson Margulies, Hervé Boutemy, Wayne Fay, Kristian Rosenvold, Olivier Lamy +1 (non-binding): Mirko Friedenhagen, Tony Chemit, Mark Derricutt, Anders Hammar, Robert Scholte, Karl Heinz Marbaise So I will continue the release process. Thanks! -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
+1 Kristian Den 17.01.2012 11:14, skrev Olivier Lamy: Hello, After some RCs, it's now time to cut the release. So I start the vote for Apache Maven 3.0.4. The release notes is available here: http://maven.apache.org/docs/3.0.4/release-notes.html The staging repo: https://repository.apache.org/content/repositories/maven-081/ For convenience builds are available here: http://people.apache.org/~olamy/maven/3.0.4/ [+1] [0] [-1] Vote open for 72H. Here my +1 Thanks, - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
hi, +1 non-binding from me... Tested with different of my projects no problems at all... Kind regards Karl Heinz Marbaise - Kind regards Karl Heinz Marbaise http://www.soebes.de http://www.skmwiki.de http://supose.org/wiki/supose -- View this message in context: http://maven.40175.n5.nabble.com/VOTE-Apache-Maven-3-0-4-tp5151173p5157498.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
+1 -Robert On Wed, 18 Jan 2012 08:32:54 +0100, Anders Hammar and...@hammar.net wrote: +1 non-binding Tested Snapshot deploy to Codehaus Nexus. Tested that site now works out-of-the-box (MNG-5221, MNG-5225). Also verified using new Maven version properties in jar manifest (MNG-4112). /Anders On Wed, Jan 18, 2012 at 01:56, Mark Derricutt m...@talios.com wrote: +1 Non binding. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Tue, Jan 17, 2012 at 11:14 PM, Olivier Lamy ol...@apache.org wrote: Hello, After some RCs, it's now time to cut the release. So I start the vote for Apache Maven 3.0.4. The release notes is available here: http://maven.apache.org/docs/3.0.4/release-notes.html The staging repo: https://repository.apache.org/content/repositories/maven-081/ For convenience builds are available here: http://people.apache.org/~olamy/maven/3.0.4/ [+1] [0] [-1] Vote open for 72H. Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
+1 binding Tested on a few work and personal projects with no regressions noted. Not doing anything particularly complicated in those builds. Wayne On Tue, Jan 17, 2012 at 4:14 AM, Olivier Lamy ol...@apache.org wrote: Hello, After some RCs, it's now time to cut the release. So I start the vote for Apache Maven 3.0.4. The release notes is available here: http://maven.apache.org/docs/3.0.4/release-notes.html The staging repo: https://repository.apache.org/content/repositories/maven-081/ For convenience builds are available here: http://people.apache.org/~olamy/maven/3.0.4/ [+1] [0] [-1] Vote open for 72H. Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Apache Maven 3.0.4
Hello, After some RCs, it's now time to cut the release. So I start the vote for Apache Maven 3.0.4. The release notes is available here: http://maven.apache.org/docs/3.0.4/release-notes.html The staging repo: https://repository.apache.org/content/repositories/maven-081/ For convenience builds are available here: http://people.apache.org/~olamy/maven/3.0.4/ [+1] [0] [-1] Vote open for 72H. Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
+1 non-binding, I ran a few jenkins jobs without problem (Linux) and some local jobs on Mac OS X Lion. Regards Mirko On Tue, Jan 17, 2012 at 11:14, Olivier Lamy ol...@apache.org wrote: Hello, After some RCs, it's now time to cut the release. So I start the vote for Apache Maven 3.0.4. The release notes is available here: http://maven.apache.org/docs/3.0.4/release-notes.html The staging repo: https://repository.apache.org/content/repositories/maven-081/ For convenience builds are available here: http://people.apache.org/~olamy/maven/3.0.4/ [+1] [0] [-1] Vote open for 72H. Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
+1 On 1/17/12 5:14 AM, Olivier Lamy wrote: Hello, After some RCs, it's now time to cut the release. So I start the vote for Apache Maven 3.0.4. The release notes is available here: http://maven.apache.org/docs/3.0.4/release-notes.html The staging repo: https://repository.apache.org/content/repositories/maven-081/ For convenience builds are available here: http://people.apache.org/~olamy/maven/3.0.4/ [+1] [0] [-1] Vote open for 72H. Here my +1 Thanks, -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
On Tue, 17 Jan 2012 11:14:02 +0100 Olivier Lamy ol...@apache.org wrote: +1 (non-binding) Tested on all projects as simple build + via jenkins. No regression detected. Nice work guys ;) Tony. Hello, After some RCs, it's now time to cut the release. So I start the vote for Apache Maven 3.0.4. The release notes is available here: http://maven.apache.org/docs/3.0.4/release-notes.html The staging repo: https://repository.apache.org/content/repositories/maven-081/ For convenience builds are available here: http://people.apache.org/~olamy/maven/3.0.4/ [+1] [0] [-1] Vote open for 72H. Here my +1 Thanks, -- Tony Chemit tél: +33 (0) 2 40 50 29 28 email: che...@codelutin.com http://www.codelutin.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
+1 Emmanuel On Tue, Jan 17, 2012 at 11:14 AM, Olivier Lamy ol...@apache.org wrote: Hello, After some RCs, it's now time to cut the release. So I start the vote for Apache Maven 3.0.4. The release notes is available here: http://maven.apache.org/docs/3.0.4/release-notes.html The staging repo: https://repository.apache.org/content/repositories/maven-081/ For convenience builds are available here: http://people.apache.org/~olamy/maven/3.0.4/ [+1] [0] [-1] Vote open for 72H. Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
+1 (binding) On Tue, Jan 17, 2012 at 5:44 PM, Emmanuel Venisse emmanuel.veni...@gmail.com wrote: +1 Emmanuel On Tue, Jan 17, 2012 at 11:14 AM, Olivier Lamy ol...@apache.org wrote: Hello, After some RCs, it's now time to cut the release. So I start the vote for Apache Maven 3.0.4. The release notes is available here: http://maven.apache.org/docs/3.0.4/release-notes.html The staging repo: https://repository.apache.org/content/repositories/maven-081/ For convenience builds are available here: http://people.apache.org/~olamy/maven/3.0.4/ [+1] [0] [-1] Vote open for 72H. Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
+1 Core ITs published as run with this release http://maven.apache.org/core-its/core-it-suite/ Hervé Le mardi 17 janvier 2012 11:14:02 Olivier Lamy a écrit : Hello, After some RCs, it's now time to cut the release. So I start the vote for Apache Maven 3.0.4. The release notes is available here: http://maven.apache.org/docs/3.0.4/release-notes.html The staging repo: https://repository.apache.org/content/repositories/maven-081/ For convenience builds are available here: http://people.apache.org/~olamy/maven/3.0.4/ [+1] [0] [-1] Vote open for 72H. Here my +1 Thanks, - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
+1 Non binding. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Tue, Jan 17, 2012 at 11:14 PM, Olivier Lamy ol...@apache.org wrote: Hello, After some RCs, it's now time to cut the release. So I start the vote for Apache Maven 3.0.4. The release notes is available here: http://maven.apache.org/docs/3.0.4/release-notes.html The staging repo: https://repository.apache.org/content/repositories/maven-081/ For convenience builds are available here: http://people.apache.org/~olamy/maven/3.0.4/ [+1] [0] [-1] Vote open for 72H. Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
+1 non-binding Tested Snapshot deploy to Codehaus Nexus. Tested that site now works out-of-the-box (MNG-5221, MNG-5225). Also verified using new Maven version properties in jar manifest (MNG-4112). /Anders On Wed, Jan 18, 2012 at 01:56, Mark Derricutt m...@talios.com wrote: +1 Non binding. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Tue, Jan 17, 2012 at 11:14 PM, Olivier Lamy ol...@apache.org wrote: Hello, After some RCs, it's now time to cut the release. So I start the vote for Apache Maven 3.0.4. The release notes is available here: http://maven.apache.org/docs/3.0.4/release-notes.html The staging repo: https://repository.apache.org/content/repositories/maven-081/ For convenience builds are available here: http://people.apache.org/~olamy/maven/3.0.4/ [+1] [0] [-1] Vote open for 72H. Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RC release naming (was Re: [VOTE] Apache Maven 3.0.4 (take 2) )
Hello everybody, I understand the need to distinguish between these attempts. I now have a local copy of 3.0.4 on my disc (as well as on some others). Next month forgetful as I am, I will not know anymore which of the different 3.0.4 copies was the blessed one. Let alone that the tag in subversion will have nothing to do with the real thing. On the other hand I do not like having things named 3.0.4-RC1..10 and when RC10 should be the good version then we try to rebuild this perfectly behaving binary once again just with a different name and break it again possibly while doing this. Here at work I try to convince my coworkers to always increase version numbers while tagging a new version, even if the change is really small. A name already taken is burnt IMO. What about introducing a fourth number (3.0.4.N) without any special semantics. Then we all could test the 3.0.4.2, would be sure we talk about the same thing (instead of the first of the attempts to release 3.0.4, you know, the one version we had to draw back which is not the same as the second attempt to release 3.0.4, you know, the second version we had to draw back ... ;-)). and when the vote passed this version 3.0.4.N would be released by communicating this to the user list and modifying the link on http://maven.apache.org/ Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ On Mon, Dec 5, 2011 at 01:44, Brian Fox bri...@infinity.nu wrote: Again I start a release process and produce a candidate for release build with a naming 3.0.4 for 5 days vote. Something failed, so it has been fixed and I restarted a vote with a second candidate for release called 3.0.4 for 5 days vote. (retagging etc ) What is the difference with producing something called RC1 (build which will never published) and rebuild after some days the SAME thing without the RC end naming ? Sorry but except some marketing naming I don't see any difference in a technical point of view (everything can be tracked in the scm). There's a big difference as we found in the past. Quoting from myself (http://www.sonatype.com/people/2008/04/quality-is-not-accidental/) The normal release process for Maven is to stage a release, email the dev list and wait for votes or show stopper issues to occur. The norm for most releases is 72 hours, but with Maven core releases it was common to let it bake for a week or more. Based on history, I was positive that the first few attempts wouldn’t make it through, so we started with a “pre vote” instead of a vote email. It seemed that each “pre vote” staged release we posted for dev list testing showed yet another how come no one noticed that? regression. It became apparent that we needed more than ever to harness the power of the full community to squash these regressions. Since tossing out multiple versions all called “2.0.9″ to such a wide audience was clearly a bad idea, we started appending -RC[x] to distinguish them. Additionally, we needed to have a set of operating parameters to guide this broad level of testing, lest we have chaos in the flood of bug fix requests. The point is we need to put something out that is a release that the wider user community will consume and provide feedback on. This has in the past been very effective at surfacing important issues that won't be found from people on the dev list, but will be found before the ink is even dry on the official release. You can see more of the reasoning here: http://mail-archives.apache.org/mod_mbox/maven-users/200804.mbox/%3c2babbe7d2a66e04db8a66a527d29927e35e...@intrepid.infinity.nu%3E This has pretty much been standard fare since 2.0.9, and I don't see a good reason to deviate. On the contrary, wagon changes are particularly hard to fully test out and having more eyes are better. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RC release naming (was Re: [VOTE] Apache Maven 3.0.4 (take 2) )
Personally, I'd rather burn 3.0.4 and have 3.0.5, 3.0.6, etc version numbers are cheap... if anyone asks what happend to 3.0.4, we just say, oh that was not released, there's a tag of it in svn, but there are no binaries or source distributions because it failed for some reason. On 5 December 2011 13:46, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Hello everybody, I understand the need to distinguish between these attempts. I now have a local copy of 3.0.4 on my disc (as well as on some others). Next month forgetful as I am, I will not know anymore which of the different 3.0.4 copies was the blessed one. Let alone that the tag in subversion will have nothing to do with the real thing. On the other hand I do not like having things named 3.0.4-RC1..10 and when RC10 should be the good version then we try to rebuild this perfectly behaving binary once again just with a different name and break it again possibly while doing this. Here at work I try to convince my coworkers to always increase version numbers while tagging a new version, even if the change is really small. A name already taken is burnt IMO. What about introducing a fourth number (3.0.4.N) without any special semantics. Then we all could test the 3.0.4.2, would be sure we talk about the same thing (instead of the first of the attempts to release 3.0.4, you know, the one version we had to draw back which is not the same as the second attempt to release 3.0.4, you know, the second version we had to draw back ... ;-)). and when the vote passed this version 3.0.4.N would be released by communicating this to the user list and modifying the link on http://maven.apache.org/ Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ On Mon, Dec 5, 2011 at 01:44, Brian Fox bri...@infinity.nu wrote: Again I start a release process and produce a candidate for release build with a naming 3.0.4 for 5 days vote. Something failed, so it has been fixed and I restarted a vote with a second candidate for release called 3.0.4 for 5 days vote. (retagging etc ) What is the difference with producing something called RC1 (build which will never published) and rebuild after some days the SAME thing without the RC end naming ? Sorry but except some marketing naming I don't see any difference in a technical point of view (everything can be tracked in the scm). There's a big difference as we found in the past. Quoting from myself (http://www.sonatype.com/people/2008/04/quality-is-not-accidental/) The normal release process for Maven is to stage a release, email the dev list and wait for votes or show stopper issues to occur. The norm for most releases is 72 hours, but with Maven core releases it was common to let it bake for a week or more. Based on history, I was positive that the first few attempts wouldn’t make it through, so we started with a “pre vote” instead of a vote email. It seemed that each “pre vote” staged release we posted for dev list testing showed yet another how come no one noticed that? regression. It became apparent that we needed more than ever to harness the power of the full community to squash these regressions. Since tossing out multiple versions all called “2.0.9″ to such a wide audience was clearly a bad idea, we started appending -RC[x] to distinguish them. Additionally, we needed to have a set of operating parameters to guide this broad level of testing, lest we have chaos in the flood of bug fix requests. The point is we need to put something out that is a release that the wider user community will consume and provide feedback on. This has in the past been very effective at surfacing important issues that won't be found from people on the dev list, but will be found before the ink is even dry on the official release. You can see more of the reasoning here: http://mail-archives.apache.org/mod_mbox/maven-users/200804.mbox/%3c2babbe7d2a66e04db8a66a527d29927e35e...@intrepid.infinity.nu%3E This has pretty much been standard fare since 2.0.9, and I don't see a good reason to deviate. On the contrary, wagon changes are particularly hard to fully test out and having more eyes are better. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RC release naming (was Re: [VOTE] Apache Maven 3.0.4 (take 2) )
On Mon, Dec 5, 2011 at 9:17 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Personally, I'd rather burn 3.0.4 and have 3.0.5, 3.0.6, etc version numbers are cheap... if anyone asks what happend to 3.0.4, we just say, oh that was not released, there's a tag of it in svn, but there are no binaries or source distributions because it failed for some reason. +1 Lots of good stuff in there already. Includes a minor set back for some use cases, but keep moving forward. There's a backlog of thousands of defects, just keep moving forward. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RC release naming (was Re: [VOTE] Apache Maven 3.0.4 (take 2) )
This approach fails to make the release candidate available to a wider community. We need to make release candidate builds available for download and from maven central repository so early adopters can try them easily. But we also need to have release candidates clearly marked as such so more conservative users know what they are. Reputation of a quality project takes very long time to build but can be lost in a one or two rushed releases. -- Regards, Igor On 11-12-05 9:17 AM, Stephen Connolly wrote: Personally, I'd rather burn 3.0.4 and have 3.0.5, 3.0.6, etc version numbers are cheap... if anyone asks what happend to 3.0.4, we just say, oh that was not released, there's a tag of it in svn, but there are no binaries or source distributions because it failed for some reason. On 5 December 2011 13:46, Mirko Friedenhagenmfriedenha...@gmail.comwrote: Hello everybody, I understand the need to distinguish between these attempts. I now have a local copy of 3.0.4 on my disc (as well as on some others). Next month forgetful as I am, I will not know anymore which of the different 3.0.4 copies was the blessed one. Let alone that the tag in subversion will have nothing to do with the real thing. On the other hand I do not like having things named 3.0.4-RC1..10 and when RC10 should be the good version then we try to rebuild this perfectly behaving binary once again just with a different name and break it again possibly while doing this. Here at work I try to convince my coworkers to always increase version numbers while tagging a new version, even if the change is really small. A name already taken is burnt IMO. What about introducing a fourth number (3.0.4.N) without any special semantics. Then we all could test the 3.0.4.2, would be sure we talk about the same thing (instead of the first of the attempts to release 3.0.4, you know, the one version we had to draw back which is not the same as the second attempt to release 3.0.4, you know, the second version we had to draw back ... ;-)). and when the vote passed this version 3.0.4.N would be released by communicating this to the user list and modifying the link on http://maven.apache.org/ Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ On Mon, Dec 5, 2011 at 01:44, Brian Foxbri...@infinity.nu wrote: Again I start a release process and produce a candidate for release build with a naming 3.0.4 for 5 days vote. Something failed, so it has been fixed and I restarted a vote with a second candidate for release called 3.0.4 for 5 days vote. (retagging etc ) What is the difference with producing something called RC1 (build which will never published) and rebuild after some days the SAME thing without the RC end naming ? Sorry but except some marketing naming I don't see any difference in a technical point of view (everything can be tracked in the scm). There's a big difference as we found in the past. Quoting from myself (http://www.sonatype.com/people/2008/04/quality-is-not-accidental/) The normal release process for Maven is to stage a release, email the dev list and wait for votes or show stopper issues to occur. The norm for most releases is 72 hours, but with Maven core releases it was common to let it bake for a week or more. Based on history, I was positive that the first few attempts wouldn’t make it through, so we started with a “pre vote” instead of a vote email. It seemed that each “pre vote” staged release we posted for dev list testing showed yet another how come no one noticed that? regression. It became apparent that we needed more than ever to harness the power of the full community to squash these regressions. Since tossing out multiple versions all called “2.0.9″ to such a wide audience was clearly a bad idea, we started appending -RC[x] to distinguish them. Additionally, we needed to have a set of operating parameters to guide this broad level of testing, lest we have chaos in the flood of bug fix requests. The point is we need to put something out that is a release that the wider user community will consume and provide feedback on. This has in the past been very effective at surfacing important issues that won't be found from people on the dev list, but will be found before the ink is even dry on the official release. You can see more of the reasoning here: http://mail-archives.apache.org/mod_mbox/maven-users/200804.mbox/%3c2babbe7d2a66e04db8a66a527d29927e35e...@intrepid.infinity.nu%3E This has pretty much been standard fare since 2.0.9, and I don't see a good reason to deviate. On the contrary, wagon changes are particularly hard to fully test out and having more eyes are better. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To
Re: RC release naming (was Re: [VOTE] Apache Maven 3.0.4 (take 2) )
But we have never made the RCs available from Maven Central. http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven%22%20AND%20a%3A%22maven-core%22 Show me an RC version in that list! On 5 December 2011 14:30, Igor Fedorenko i...@ifedorenko.com wrote: This approach fails to make the release candidate available to a wider community. We need to make release candidate builds available for download and from maven central repository so early adopters can try them easily. But we also need to have release candidates clearly marked as such so more conservative users know what they are. Reputation of a quality project takes very long time to build but can be lost in a one or two rushed releases. -- Regards, Igor On 11-12-05 9:17 AM, Stephen Connolly wrote: Personally, I'd rather burn 3.0.4 and have 3.0.5, 3.0.6, etc version numbers are cheap... if anyone asks what happend to 3.0.4, we just say, oh that was not released, there's a tag of it in svn, but there are no binaries or source distributions because it failed for some reason. On 5 December 2011 13:46, Mirko Friedenhagenmfriedenhagen@**gmail.commfriedenha...@gmail.com wrote: Hello everybody, I understand the need to distinguish between these attempts. I now have a local copy of 3.0.4 on my disc (as well as on some others). Next month forgetful as I am, I will not know anymore which of the different 3.0.4 copies was the blessed one. Let alone that the tag in subversion will have nothing to do with the real thing. On the other hand I do not like having things named 3.0.4-RC1..10 and when RC10 should be the good version then we try to rebuild this perfectly behaving binary once again just with a different name and break it again possibly while doing this. Here at work I try to convince my coworkers to always increase version numbers while tagging a new version, even if the change is really small. A name already taken is burnt IMO. What about introducing a fourth number (3.0.4.N) without any special semantics. Then we all could test the 3.0.4.2, would be sure we talk about the same thing (instead of the first of the attempts to release 3.0.4, you know, the one version we had to draw back which is not the same as the second attempt to release 3.0.4, you know, the second version we had to draw back ... ;-)). and when the vote passed this version 3.0.4.N would be released by communicating this to the user list and modifying the link on http://maven.apache.org/ Regards Mirko -- http://illegalstateexception.**blogspot.com/http://illegalstateexception.blogspot.com/ https://github.com/**mfriedenhagen/ https://github.com/mfriedenhagen/ https://bitbucket.org/**mfriedenhagen/https://bitbucket.org/mfriedenhagen/ On Mon, Dec 5, 2011 at 01:44, Brian Foxbri...@infinity.nu wrote: Again I start a release process and produce a candidate for release build with a naming 3.0.4 for 5 days vote. Something failed, so it has been fixed and I restarted a vote with a second candidate for release called 3.0.4 for 5 days vote. (retagging etc ) What is the difference with producing something called RC1 (build which will never published) and rebuild after some days the SAME thing without the RC end naming ? Sorry but except some marketing naming I don't see any difference in a technical point of view (everything can be tracked in the scm). There's a big difference as we found in the past. Quoting from myself (http://www.sonatype.com/**people/2008/04/quality-is-not-**accidental/http://www.sonatype.com/people/2008/04/quality-is-not-accidental/ ) The normal release process for Maven is to stage a release, email the dev list and wait for votes or show stopper issues to occur. The norm for most releases is 72 hours, but with Maven core releases it was common to let it bake for a week or more. Based on history, I was positive that the first few attempts wouldn’t make it through, so we started with a “pre vote” instead of a vote email. It seemed that each “pre vote” staged release we posted for dev list testing showed yet another how come no one noticed that? regression. It became apparent that we needed more than ever to harness the power of the full community to squash these regressions. Since tossing out multiple versions all called “2.0.9″ to such a wide audience was clearly a bad idea, we started appending -RC[x] to distinguish them. Additionally, we needed to have a set of operating parameters to guide this broad level of testing, lest we have chaos in the flood of bug fix requests. The point is we need to put something out that is a release that the wider user community will consume and provide feedback on. This has in the past been very effective at surfacing important issues that won't be found from people on the dev list, but will be found before the ink is even dry on the official release. You can see more of the reasoning here:
Re: RC release naming (was Re: [VOTE] Apache Maven 3.0.4 (take 2) )
2011/12/5 Stephen Connolly stephen.alan.conno...@gmail.com: Personally, I'd rather burn 3.0.4 and have 3.0.5, 3.0.6, etc version numbers are cheap... if anyone asks what happend to 3.0.4, we just say, oh that was not released, there's a tag of it in svn, but there are no binaries or source distributions because it failed for some reason. agree even if it's pretty similar to 3.0.4-RCn :-) BTW it's too late I have staged a 3.0.4-RC3 (it was very difficult for me to choose RC1 or RC3 :-) ). At least in a technical POV providing different number, is better to prevent various MRM which cache release artifacts. For people consuming those artifacts, it can be a pain to cleanup a chain of cached artifact. So let concentrate on coding (improvement and issue fixes rather than such non end discussions as probably never everybody will agree :-) IMHO ). On 5 December 2011 13:46, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Hello everybody, I understand the need to distinguish between these attempts. I now have a local copy of 3.0.4 on my disc (as well as on some others). Next month forgetful as I am, I will not know anymore which of the different 3.0.4 copies was the blessed one. Let alone that the tag in subversion will have nothing to do with the real thing. On the other hand I do not like having things named 3.0.4-RC1..10 and when RC10 should be the good version then we try to rebuild this perfectly behaving binary once again just with a different name and break it again possibly while doing this. Here at work I try to convince my coworkers to always increase version numbers while tagging a new version, even if the change is really small. A name already taken is burnt IMO. What about introducing a fourth number (3.0.4.N) without any special semantics. Then we all could test the 3.0.4.2, would be sure we talk about the same thing (instead of the first of the attempts to release 3.0.4, you know, the one version we had to draw back which is not the same as the second attempt to release 3.0.4, you know, the second version we had to draw back ... ;-)). and when the vote passed this version 3.0.4.N would be released by communicating this to the user list and modifying the link on http://maven.apache.org/ Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ On Mon, Dec 5, 2011 at 01:44, Brian Fox bri...@infinity.nu wrote: Again I start a release process and produce a candidate for release build with a naming 3.0.4 for 5 days vote. Something failed, so it has been fixed and I restarted a vote with a second candidate for release called 3.0.4 for 5 days vote. (retagging etc ) What is the difference with producing something called RC1 (build which will never published) and rebuild after some days the SAME thing without the RC end naming ? Sorry but except some marketing naming I don't see any difference in a technical point of view (everything can be tracked in the scm). There's a big difference as we found in the past. Quoting from myself (http://www.sonatype.com/people/2008/04/quality-is-not-accidental/) The normal release process for Maven is to stage a release, email the dev list and wait for votes or show stopper issues to occur. The norm for most releases is 72 hours, but with Maven core releases it was common to let it bake for a week or more. Based on history, I was positive that the first few attempts wouldn’t make it through, so we started with a “pre vote” instead of a vote email. It seemed that each “pre vote” staged release we posted for dev list testing showed yet another how come no one noticed that? regression. It became apparent that we needed more than ever to harness the power of the full community to squash these regressions. Since tossing out multiple versions all called “2.0.9″ to such a wide audience was clearly a bad idea, we started appending -RC[x] to distinguish them. Additionally, we needed to have a set of operating parameters to guide this broad level of testing, lest we have chaos in the flood of bug fix requests. The point is we need to put something out that is a release that the wider user community will consume and provide feedback on. This has in the past been very effective at surfacing important issues that won't be found from people on the dev list, but will be found before the ink is even dry on the official release. You can see more of the reasoning here: http://mail-archives.apache.org/mod_mbox/maven-users/200804.mbox/%3c2babbe7d2a66e04db8a66a527d29927e35e...@intrepid.infinity.nu%3E This has pretty much been standard fare since 2.0.9, and I don't see a good reason to deviate. On the contrary, wagon changes are particularly hard to fully test out and having more eyes are better. - To
Re: RC release naming (was Re: [VOTE] Apache Maven 3.0.4 (take 2) )
Well I would say, given the confusion over RCs or not RCs that when you spin the official build, just build it as 3.0.5 so that there is no official 3.0.4 and anyone who had one of the first two RCs can be clear that it was an RC On 5 December 2011 14:33, Olivier Lamy ol...@apache.org wrote: 2011/12/5 Stephen Connolly stephen.alan.conno...@gmail.com: Personally, I'd rather burn 3.0.4 and have 3.0.5, 3.0.6, etc version numbers are cheap... if anyone asks what happend to 3.0.4, we just say, oh that was not released, there's a tag of it in svn, but there are no binaries or source distributions because it failed for some reason. agree even if it's pretty similar to 3.0.4-RCn :-) BTW it's too late I have staged a 3.0.4-RC3 (it was very difficult for me to choose RC1 or RC3 :-) ). At least in a technical POV providing different number, is better to prevent various MRM which cache release artifacts. For people consuming those artifacts, it can be a pain to cleanup a chain of cached artifact. So let concentrate on coding (improvement and issue fixes rather than such non end discussions as probably never everybody will agree :-) IMHO ). On 5 December 2011 13:46, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello everybody, I understand the need to distinguish between these attempts. I now have a local copy of 3.0.4 on my disc (as well as on some others). Next month forgetful as I am, I will not know anymore which of the different 3.0.4 copies was the blessed one. Let alone that the tag in subversion will have nothing to do with the real thing. On the other hand I do not like having things named 3.0.4-RC1..10 and when RC10 should be the good version then we try to rebuild this perfectly behaving binary once again just with a different name and break it again possibly while doing this. Here at work I try to convince my coworkers to always increase version numbers while tagging a new version, even if the change is really small. A name already taken is burnt IMO. What about introducing a fourth number (3.0.4.N) without any special semantics. Then we all could test the 3.0.4.2, would be sure we talk about the same thing (instead of the first of the attempts to release 3.0.4, you know, the one version we had to draw back which is not the same as the second attempt to release 3.0.4, you know, the second version we had to draw back ... ;-)). and when the vote passed this version 3.0.4.N would be released by communicating this to the user list and modifying the link on http://maven.apache.org/ Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ On Mon, Dec 5, 2011 at 01:44, Brian Fox bri...@infinity.nu wrote: Again I start a release process and produce a candidate for release build with a naming 3.0.4 for 5 days vote. Something failed, so it has been fixed and I restarted a vote with a second candidate for release called 3.0.4 for 5 days vote. (retagging etc ) What is the difference with producing something called RC1 (build which will never published) and rebuild after some days the SAME thing without the RC end naming ? Sorry but except some marketing naming I don't see any difference in a technical point of view (everything can be tracked in the scm). There's a big difference as we found in the past. Quoting from myself (http://www.sonatype.com/people/2008/04/quality-is-not-accidental/) The normal release process for Maven is to stage a release, email the dev list and wait for votes or show stopper issues to occur. The norm for most releases is 72 hours, but with Maven core releases it was common to let it bake for a week or more. Based on history, I was positive that the first few attempts wouldn’t make it through, so we started with a “pre vote” instead of a vote email. It seemed that each “pre vote” staged release we posted for dev list testing showed yet another how come no one noticed that? regression. It became apparent that we needed more than ever to harness the power of the full community to squash these regressions. Since tossing out multiple versions all called “2.0.9″ to such a wide audience was clearly a bad idea, we started appending -RC[x] to distinguish them. Additionally, we needed to have a set of operating parameters to guide this broad level of testing, lest we have chaos in the flood of bug fix requests. The point is we need to put something out that is a release that the wider user community will consume and provide feedback on. This has in the past been very effective at surfacing important issues that won't be found from people on the dev list, but will be found before the ink is even dry on the official release. You can see more of the reasoning here:
Re: RC release naming (was Re: [VOTE] Apache Maven 3.0.4 (take 2) )
Fair enough. I confused RC with alpha/beta versions we had in the past. I can't recall if RCs were available from download page, though. -- Regards, Igor On 11-12-05 9:33 AM, Stephen Connolly wrote: But we have never made the RCs available from Maven Central. http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven%22%20AND%20a%3A%22maven-core%22 Show me an RC version in that list! On 5 December 2011 14:30, Igor Fedorenkoi...@ifedorenko.com wrote: This approach fails to make the release candidate available to a wider community. We need to make release candidate builds available for download and from maven central repository so early adopters can try them easily. But we also need to have release candidates clearly marked as such so more conservative users know what they are. Reputation of a quality project takes very long time to build but can be lost in a one or two rushed releases. -- Regards, Igor On 11-12-05 9:17 AM, Stephen Connolly wrote: Personally, I'd rather burn 3.0.4 and have 3.0.5, 3.0.6, etc version numbers are cheap... if anyone asks what happend to 3.0.4, we just say, oh that was not released, there's a tag of it in svn, but there are no binaries or source distributions because it failed for some reason. On 5 December 2011 13:46, Mirko Friedenhagenmfriedenhagen@**gmail.commfriedenha...@gmail.com wrote: Hello everybody, I understand the need to distinguish between these attempts. I now have a local copy of 3.0.4 on my disc (as well as on some others). Next month forgetful as I am, I will not know anymore which of the different 3.0.4 copies was the blessed one. Let alone that the tag in subversion will have nothing to do with the real thing. On the other hand I do not like having things named 3.0.4-RC1..10 and when RC10 should be the good version then we try to rebuild this perfectly behaving binary once again just with a different name and break it again possibly while doing this. Here at work I try to convince my coworkers to always increase version numbers while tagging a new version, even if the change is really small. A name already taken is burnt IMO. What about introducing a fourth number (3.0.4.N) without any special semantics. Then we all could test the 3.0.4.2, would be sure we talk about the same thing (instead of the first of the attempts to release 3.0.4, you know, the one version we had to draw back which is not the same as the second attempt to release 3.0.4, you know, the second version we had to draw back ... ;-)). and when the vote passed this version 3.0.4.N would be released by communicating this to the user list and modifying the link on http://maven.apache.org/ Regards Mirko -- http://illegalstateexception.**blogspot.com/http://illegalstateexception.blogspot.com/ https://github.com/**mfriedenhagen/https://github.com/mfriedenhagen/ https://bitbucket.org/**mfriedenhagen/https://bitbucket.org/mfriedenhagen/ On Mon, Dec 5, 2011 at 01:44, Brian Foxbri...@infinity.nu wrote: Again I start a release process and produce a candidate for release build with a naming 3.0.4 for 5 days vote. Something failed, so it has been fixed and I restarted a vote with a second candidate for release called 3.0.4 for 5 days vote. (retagging etc ) What is the difference with producing something called RC1 (build which will never published) and rebuild after some days the SAME thing without the RC end naming ? Sorry but except some marketing naming I don't see any difference in a technical point of view (everything can be tracked in the scm). There's a big difference as we found in the past. Quoting from myself (http://www.sonatype.com/**people/2008/04/quality-is-not-**accidental/http://www.sonatype.com/people/2008/04/quality-is-not-accidental/ ) The normal release process for Maven is to stage a release, email the dev list and wait for votes or show stopper issues to occur. The norm for most releases is 72 hours, but with Maven core releases it was common to let it bake for a week or more. Based on history, I was positive that the first few attempts wouldn’t make it through, so we started with a “pre vote” instead of a vote email. It seemed that each “pre vote” staged release we posted for dev list testing showed yet another how come no one noticed that? regression. It became apparent that we needed more than ever to harness the power of the full community to squash these regressions. Since tossing out multiple versions all called “2.0.9″ to such a wide audience was clearly a bad idea, we started appending -RC[x] to distinguish them. Additionally, we needed to have a set of operating parameters to guide this broad level of testing, lest we have chaos in the flood of bug fix requests. The point is we need to put something out that is a release that the wider user community will consume and provide feedback on. This has in the past been very effective at surfacing important issues that won't be found from people on the dev list, but will be
Re: RC release naming (was Re: [VOTE] Apache Maven 3.0.4 (take 2) )
Totally agreed, my point was uniqueness and reproducabilty, so 3.0.5 etc. would be perfect IMO. Regards Mirko -- Sent from my phone http://illegalstateexception.blogspot.com http://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ On Dec 5, 2011 3:18 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Personally, I'd rather burn 3.0.4 and have 3.0.5, 3.0.6, etc version numbers are cheap... if anyone asks what happend to 3.0.4, we just say, oh that was not released, there's a tag of it in svn, but there are no binaries or source distributions because it failed for some reason. On 5 December 2011 13:46, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello everybody, I understand the need to distinguish between these attempts. I now have a local copy of 3.0.4 on my disc (as well as on some others). Next month forgetful as I am, I will not know anymore which of the different 3.0.4 copies was the blessed one. Let alone that the tag in subversion will have nothing to do with the real thing. On the other hand I do not like having things named 3.0.4-RC1..10 and when RC10 should be the good version then we try to rebuild this perfectly behaving binary once again just with a different name and break it again possibly while doing this. Here at work I try to convince my coworkers to always increase version numbers while tagging a new version, even if the change is really small. A name already taken is burnt IMO. What about introducing a fourth number (3.0.4.N) without any special semantics. Then we all could test the 3.0.4.2, would be sure we talk about the same thing (instead of the first of the attempts to release 3.0.4, you know, the one version we had to draw back which is not the same as the second attempt to release 3.0.4, you know, the second version we had to draw back ... ;-)). and when the vote passed this version 3.0.4.N would be released by communicating this to the user list and modifying the link on http://maven.apache.org/ Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ On Mon, Dec 5, 2011 at 01:44, Brian Fox bri...@infinity.nu wrote: Again I start a release process and produce a candidate for release build with a naming 3.0.4 for 5 days vote. Something failed, so it has been fixed and I restarted a vote with a second candidate for release called 3.0.4 for 5 days vote. (retagging etc ) What is the difference with producing something called RC1 (build which will never published) and rebuild after some days the SAME thing without the RC end naming ? Sorry but except some marketing naming I don't see any difference in a technical point of view (everything can be tracked in the scm). There's a big difference as we found in the past. Quoting from myself (http://www.sonatype.com/people/2008/04/quality-is-not-accidental/) The normal release process for Maven is to stage a release, email the dev list and wait for votes or show stopper issues to occur. The norm for most releases is 72 hours, but with Maven core releases it was common to let it bake for a week or more. Based on history, I was positive that the first few attempts wouldn’t make it through, so we started with a “pre vote” instead of a vote email. It seemed that each “pre vote” staged release we posted for dev list testing showed yet another how come no one noticed that? regression. It became apparent that we needed more than ever to harness the power of the full community to squash these regressions. Since tossing out multiple versions all called “2.0.9″ to such a wide audience was clearly a bad idea, we started appending -RC[x] to distinguish them. Additionally, we needed to have a set of operating parameters to guide this broad level of testing, lest we have chaos in the flood of bug fix requests. The point is we need to put something out that is a release that the wider user community will consume and provide feedback on. This has in the past been very effective at surfacing important issues that won't be found from people on the dev list, but will be found before the ink is even dry on the official release. You can see more of the reasoning here: http://mail-archives.apache.org/mod_mbox/maven-users/200804.mbox/%3c2babbe7d2a66e04db8a66a527d29927e35e...@intrepid.infinity.nu%3E This has pretty much been standard fare since 2.0.9, and I don't see a good reason to deviate. On the contrary, wagon changes are particularly hard to fully test out and having more eyes are better. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
Thanks to you for the test sample. I will cancel the vote and investigate more on monday (as not sure to have enough time on this sunday) My first impression is a side effect of this fix: https://issues.sonatype.org/browse/AETHER-91. But need more investigation. -- Olivier 2011/12/4 Dan Tran dant...@gmail.com: Thanks for looking into this issue. consider it is a blocking regression since there is no work around for me to use 3.0.4 \-D On Sat, Dec 3, 2011 at 1:47 PM, Olivier Lamy ol...@apache.org wrote: Thanks! It looks an erroneous file is picked when it has been download from a remote repo and when it's reinstall locally (use case of appassembler which reinstall file locally) investigating... 2011/12/3 Dan Tran dant...@gmail.com: here is sample pom.xml to reproduce the issue. 3.0.3 generate the correct lib dir, and script, but not 3.0.4 project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdmy.groupId/groupId artifactIdmyArtifactId/artifactId version1-SNAPSHOT/version packagingjar/packaging dependencies dependency groupIdcommons-cli/groupId artifactIdcommons-cli/artifactId version1.3-SNAPSHOT/version /dependency /dependencies build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdappassembler-maven-plugin/artifactId version1.1.1/version executions execution idgenerate-setup-scripts/id phaseprepare-package/phase goals goalassemble/goal /goals configuration repositoryLayoutflat/repositoryLayout generateRepositorytrue/generateRepository repositoryNamelib/repositoryName programs program mainClassfake.Main/mainClass namesetup/name /program /programs platforms platformunix/platform /platforms /configuration /execution /executions /plugin /plugins /build /project On Sat, Dec 3, 2011 at 8:42 AM, Brian Fox bri...@infinity.nu wrote: The RCs were started for a very specific reason, to improve the quality of our releases. Just breezing through this thread, there are clearly issues with memory and some other stuff here that may be bigger than we understand in this small testing surface. An RC build will get more eyes and either confirm these aren't a big deal, or they are. Reminder of where we were with 2.0.7, 2.0.8 and why we do RCs: http://www.sonatype.com/people/2008/04/quality-is-not-accidental/ I'm -1 on a release without some RCs. On Thu, Dec 1, 2011 at 3:17 PM, John Casey jdca...@commonjava.org wrote: On 12/1/11 10:27 AM, Olivier Lamy wrote: 2011/12/1 Jörg Schaiblejoerg.schai...@scalaris.com: Benjamin Bentmann wrote: Olivier Lamy wrote: I'd like to release Apache Maven 3.0.4 (take 2). [...] Note the difference with first vote is an upgrade of aether to 1.13.1 What about the memory issue that Jörg brought up? Shouldn't we at least understand the cause and potential impact on other users before continuing the release? Continue, I'll report later, but it seems that there's no regression in 304 vs 303. Thanks! @Benjamin: I tend to say we must release it (maybe the famous early and often' :-) ). Early-and-often is great, but it's not an excuse to be lax on quality standards. Hudson had some famously horrible releases early on, and I suspect they had to do with sacrificing concerns about quality on the altar of early-and-often. An RC would take less than a week more if the code really is ready to go. If it's not, then we don't want to release it, do we? My goal is to provide a release point (stable tagged build) to get feedbacks. Trying to reach/wait the perfect release without those feedbacks is IMHO impossible. Actually it's not; the feedback comes by way of RCs. This is why it's so important to do RCs for Maven core. Maybe we can skip the RC process on plugins (I tend to think a single, quick RC is still a good idea there), but the core is far, far more complex. Even with a huge IT set we cannot hope to cover all use cases there, so it's simply not enough. If Jörg's issue doesn't pop up in this staged release, then I'd say let's just learn that lesson for next time. It takes a little longer using RCs, but it's the ONLY way we've been able to produce releases that weren't riddled with regressions in the past. Even with a strong IT suite, it's still good practice. As an aside, we might as well call this staging of 3.0.4 a RC and discuss it here as if it was. The main difference is procedural IMO, in that this is a
[CANCELLED] [VOTE] Apache Maven 3.0.4 (take 2)
Hello, The vote is cancelled due to the issue found by Dan. I will restart a vote when a fix will be available. 2011/12/1 Olivier Lamy ol...@apache.org: Hello, I'd like to release Apache Maven 3.0.4 (take 2). We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 Note the difference with first vote is an upgrade of aether to 1.13.1 (to prevent chuncked transfer encoding when deploying md5/sha1 files http(s): mode which is not supported by ngnix). And ref site (http://maven.apache.org/ref/3.0.4/) which now use the new fluido skin (wait sync). The staged repo is available here: https://repository.apache.org/content/repositories/maven-283/ The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote. [+1] [0] [-1] Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [CANCELLED] [VOTE] Apache Maven 3.0.4 (take 2)
On Sun, Dec 4, 2011 at 3:37 AM, Olivier Lamy ol...@apache.org wrote: Hello, The vote is cancelled due to the issue found by Dan. I will restart a vote when a fix will be available. An RC candidate I hope... 2011/12/1 Olivier Lamy ol...@apache.org: Hello, I'd like to release Apache Maven 3.0.4 (take 2). We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 Note the difference with first vote is an upgrade of aether to 1.13.1 (to prevent chuncked transfer encoding when deploying md5/sha1 files http(s): mode which is not supported by ngnix). And ref site (http://maven.apache.org/ref/3.0.4/) which now use the new fluido skin (wait sync). The staged repo is available here: https://repository.apache.org/content/repositories/maven-283/ The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote. [+1] [0] [-1] Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [CANCELLED] [VOTE] Apache Maven 3.0.4 (take 2)
On Sun, Dec 4, 2011 at 12:40 PM, Brian Fox bri...@infinity.nu wrote: On Sun, Dec 4, 2011 at 3:37 AM, Olivier Lamy ol...@apache.org wrote: Hello, The vote is cancelled due to the issue found by Dan. I will restart a vote when a fix will be available. An RC candidate I hope... Do you work for the department of redundancy department, perchance? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [CANCELLED] [VOTE] Apache Maven 3.0.4 (take 2)
2011/12/4 Brian Fox bri...@infinity.nu: On Sun, Dec 4, 2011 at 3:37 AM, Olivier Lamy ol...@apache.org wrote: Hello, The vote is cancelled due to the issue found by Dan. I will restart a vote when a fix will be available. An RC candidate I hope... That will be a surprise :-) I was off today so didn't have a look at the code to fix the regression. Why not if the fix can have some side effect. In an other thread, I have explained my POV, feel free to convince me why it's technically better in this thread. (generally I have or at least try to have an open mind :-) ) 2011/12/1 Olivier Lamy ol...@apache.org: Hello, I'd like to release Apache Maven 3.0.4 (take 2). We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 Note the difference with first vote is an upgrade of aether to 1.13.1 (to prevent chuncked transfer encoding when deploying md5/sha1 files http(s): mode which is not supported by ngnix). And ref site (http://maven.apache.org/ref/3.0.4/) which now use the new fluido skin (wait sync). The staged repo is available here: https://repository.apache.org/content/repositories/maven-283/ The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote. [+1] [0] [-1] Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RC release naming (was Re: [VOTE] Apache Maven 3.0.4 (take 2) )
Again I start a release process and produce a candidate for release build with a naming 3.0.4 for 5 days vote. Something failed, so it has been fixed and I restarted a vote with a second candidate for release called 3.0.4 for 5 days vote. (retagging etc ) What is the difference with producing something called RC1 (build which will never published) and rebuild after some days the SAME thing without the RC end naming ? Sorry but except some marketing naming I don't see any difference in a technical point of view (everything can be tracked in the scm). There's a big difference as we found in the past. Quoting from myself (http://www.sonatype.com/people/2008/04/quality-is-not-accidental/) The normal release process for Maven is to stage a release, email the dev list and wait for votes or show stopper issues to occur. The norm for most releases is 72 hours, but with Maven core releases it was common to let it bake for a week or more. Based on history, I was positive that the first few attempts wouldn’t make it through, so we started with a “pre vote” instead of a vote email. It seemed that each “pre vote” staged release we posted for dev list testing showed yet another how come no one noticed that? regression. It became apparent that we needed more than ever to harness the power of the full community to squash these regressions. Since tossing out multiple versions all called “2.0.9″ to such a wide audience was clearly a bad idea, we started appending -RC[x] to distinguish them. Additionally, we needed to have a set of operating parameters to guide this broad level of testing, lest we have chaos in the flood of bug fix requests. The point is we need to put something out that is a release that the wider user community will consume and provide feedback on. This has in the past been very effective at surfacing important issues that won't be found from people on the dev list, but will be found before the ink is even dry on the official release. You can see more of the reasoning here: http://mail-archives.apache.org/mod_mbox/maven-users/200804.mbox/%3c2babbe7d2a66e04db8a66a527d29927e35e...@intrepid.infinity.nu%3E This has pretty much been standard fare since 2.0.9, and I don't see a good reason to deviate. On the contrary, wagon changes are particularly hard to fully test out and having more eyes are better. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
2011/12/3 Dan Tran dant...@gmail.com: When using 3.0.4 with appassemble-maven-plugin to generate java wrapper scripts which use snapshot dependency. The plugin places the dependencies to its lib/repo directory using timestamp snapshots picked up from maven repo, but generated scripts using '-SNAPSHOT' for its classpath. this breaks my runtime. There is no issue with 3.0.3. Do others see the same issue? Tested with a project who use app assembler and didn't see the issue. When you test with 3.0.4 and 3.0.3: is it with an empty repo ? or a repo populated with the SNAPSHOT deps coming from remote repos ? or did you install locally those SNAPSHOT deps ? or are they part of reactor ? Do you have a sample project to reproduce ? Thanks -D On Fri, Dec 2, 2011 at 12:39 PM, John Casey jdca...@commonjava.org wrote: I've done several medium sized builds and everything looks okay here. +1 On 12/1/11 4:20 AM, Olivier Lamy wrote: Hello, I'd like to release Apache Maven 3.0.4 (take 2). We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 Note the difference with first vote is an upgrade of aether to 1.13.1 (to prevent chuncked transfer encoding when deploying md5/sha1 files http(s): mode which is not supported by ngnix). And ref site (http://maven.apache.org/ref/3.0.4/) which now use the new fluido skin (wait sync). The staged repo is available here: https://repository.apache.org/content/repositories/maven-283/ The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote. [+1] [0] [-1] Here my +1 Thanks, -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
The RCs were started for a very specific reason, to improve the quality of our releases. Just breezing through this thread, there are clearly issues with memory and some other stuff here that may be bigger than we understand in this small testing surface. An RC build will get more eyes and either confirm these aren't a big deal, or they are. Reminder of where we were with 2.0.7, 2.0.8 and why we do RCs: http://www.sonatype.com/people/2008/04/quality-is-not-accidental/ I'm -1 on a release without some RCs. On Thu, Dec 1, 2011 at 3:17 PM, John Casey jdca...@commonjava.org wrote: On 12/1/11 10:27 AM, Olivier Lamy wrote: 2011/12/1 Jörg Schaiblejoerg.schai...@scalaris.com: Benjamin Bentmann wrote: Olivier Lamy wrote: I'd like to release Apache Maven 3.0.4 (take 2). [...] Note the difference with first vote is an upgrade of aether to 1.13.1 What about the memory issue that Jörg brought up? Shouldn't we at least understand the cause and potential impact on other users before continuing the release? Continue, I'll report later, but it seems that there's no regression in 304 vs 303. Thanks! @Benjamin: I tend to say we must release it (maybe the famous early and often' :-) ). Early-and-often is great, but it's not an excuse to be lax on quality standards. Hudson had some famously horrible releases early on, and I suspect they had to do with sacrificing concerns about quality on the altar of early-and-often. An RC would take less than a week more if the code really is ready to go. If it's not, then we don't want to release it, do we? My goal is to provide a release point (stable tagged build) to get feedbacks. Trying to reach/wait the perfect release without those feedbacks is IMHO impossible. Actually it's not; the feedback comes by way of RCs. This is why it's so important to do RCs for Maven core. Maybe we can skip the RC process on plugins (I tend to think a single, quick RC is still a good idea there), but the core is far, far more complex. Even with a huge IT set we cannot hope to cover all use cases there, so it's simply not enough. If Jörg's issue doesn't pop up in this staged release, then I'd say let's just learn that lesson for next time. It takes a little longer using RCs, but it's the ONLY way we've been able to produce releases that weren't riddled with regressions in the past. Even with a strong IT suite, it's still good practice. As an aside, we might as well call this staging of 3.0.4 a RC and discuss it here as if it was. The main difference is procedural IMO, in that this is a [VOTE] thread, not a [DISCUSS] thread about whether the staged RC is ready to go. IMO that's an important distinction, since the 72h time limit is lurking nearby, but we'd still want to time-box the review of any RC The previous issue for ngnix users was blocker as some oss forge use it. So I cancel it and restart one (and thanks for the fast aether change). But for such memory issue at least users can change MAVEN_OPTS. My email [1] to Jörg describe various things to test on his private company build (I hope he will have time to provide such feedbacks with a stable maven build) Cheers, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RC release naming (was Re: [VOTE] Apache Maven 3.0.4 (take 2) )
Please change subject as it's not related to the vote thread. 2011/12/3 Brian Fox bri...@infinity.nu: The RCs were started for a very specific reason, to improve the quality of our releases. Just breezing through this thread, there are clearly issues with memory and some other stuff here that may be Most of projects I have tested doesn't show that (and believe me I have tested a lot sure not releasing on a ngnix server :-) ). But If I correctly read those mails (http://markmail.org/message/sfqixs2gd6hbwct5 or http://markmail.org/message/bhczmcrcimkdp6f2), I don't see sometimes related with this candidate for release build. Quoted: The dedicated build server is of arch amd64 and as it turned out, the PermGen space consumption on that arch is even worse. Even with 256m PermGen space the build stops with an OOME: PermGen space after 45 of 417 projects. However, M303 and M304 behave *exactly* the same (multiple runs for each). Even for M221 the build stops now after 55 projects (but different build order compared to M30x). So the good news: No regression with M304. The bad news: Something consumes PermGen space meanwhile really fast. It might be as well one of the plugins that have been updated in the last 3 of 4 months :-/ Sorry maybe as I'm not a native english reader, I misunderstand something. bigger than we understand in this small testing surface. An RC build will get more eyes and either confirm these aren't a big deal, or they are. Reminder of where we were with 2.0.7, 2.0.8 and why we do RCs: http://www.sonatype.com/people/2008/04/quality-is-not-accidental/ I'm -1 on a release without some RCs. As your mail is in the release vote does this -1 apply on the release ? Again I start a release process and produce a candidate for release build with a naming 3.0.4 for 5 days vote. Something failed, so it has been fixed and I restarted a vote with a second candidate for release called 3.0.4 for 5 days vote. (retagging etc ) What is the difference with producing something called RC1 (build which will never published) and rebuild after some days the SAME thing without the RC end naming ? Sorry but except some marketing naming I don't see any difference in a technical point of view (everything can be tracked in the scm). *Again* as already said I don't have any issues using this rc mode, if this vote fail, I will use it. -- Olivier hacker not marketer :-) On Thu, Dec 1, 2011 at 3:17 PM, John Casey jdca...@commonjava.org wrote: On 12/1/11 10:27 AM, Olivier Lamy wrote: 2011/12/1 Jörg Schaiblejoerg.schai...@scalaris.com: Benjamin Bentmann wrote: Olivier Lamy wrote: I'd like to release Apache Maven 3.0.4 (take 2). [...] Note the difference with first vote is an upgrade of aether to 1.13.1 What about the memory issue that Jörg brought up? Shouldn't we at least understand the cause and potential impact on other users before continuing the release? Continue, I'll report later, but it seems that there's no regression in 304 vs 303. Thanks! @Benjamin: I tend to say we must release it (maybe the famous early and often' :-) ). Early-and-often is great, but it's not an excuse to be lax on quality standards. Hudson had some famously horrible releases early on, and I suspect they had to do with sacrificing concerns about quality on the altar of early-and-often. An RC would take less than a week more if the code really is ready to go. If it's not, then we don't want to release it, do we? My goal is to provide a release point (stable tagged build) to get feedbacks. Trying to reach/wait the perfect release without those feedbacks is IMHO impossible. Actually it's not; the feedback comes by way of RCs. This is why it's so important to do RCs for Maven core. Maybe we can skip the RC process on plugins (I tend to think a single, quick RC is still a good idea there), but the core is far, far more complex. Even with a huge IT set we cannot hope to cover all use cases there, so it's simply not enough. If Jörg's issue doesn't pop up in this staged release, then I'd say let's just learn that lesson for next time. It takes a little longer using RCs, but it's the ONLY way we've been able to produce releases that weren't riddled with regressions in the past. Even with a strong IT suite, it's still good practice. As an aside, we might as well call this staging of 3.0.4 a RC and discuss it here as if it was. The main difference is procedural IMO, in that this is a [VOTE] thread, not a [DISCUSS] thread about whether the staged RC is ready to go. IMO that's an important distinction, since the 72h time limit is lurking nearby, but we'd still want to time-box the review of any RC The previous issue for ngnix users was blocker as some oss forge use it. So I cancel it and restart one (and thanks for the fast aether change). But for such memory issue at least users can change MAVEN_OPTS. My email [1] to Jörg describe various things to test on his
Re: [VOTE] Apache Maven 3.0.4 (take 2)
here is sample pom.xml to reproduce the issue. 3.0.3 generate the correct lib dir, and script, but not 3.0.4 project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdmy.groupId/groupId artifactIdmyArtifactId/artifactId version1-SNAPSHOT/version packagingjar/packaging dependencies dependency groupIdcommons-cli/groupId artifactIdcommons-cli/artifactId version1.3-SNAPSHOT/version /dependency /dependencies build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdappassembler-maven-plugin/artifactId version1.1.1/version executions execution idgenerate-setup-scripts/id phaseprepare-package/phase goals goalassemble/goal /goals configuration repositoryLayoutflat/repositoryLayout generateRepositorytrue/generateRepository repositoryNamelib/repositoryName programs program mainClassfake.Main/mainClass namesetup/name /program /programs platforms platformunix/platform /platforms /configuration /execution /executions /plugin /plugins /build /project On Sat, Dec 3, 2011 at 8:42 AM, Brian Fox bri...@infinity.nu wrote: The RCs were started for a very specific reason, to improve the quality of our releases. Just breezing through this thread, there are clearly issues with memory and some other stuff here that may be bigger than we understand in this small testing surface. An RC build will get more eyes and either confirm these aren't a big deal, or they are. Reminder of where we were with 2.0.7, 2.0.8 and why we do RCs: http://www.sonatype.com/people/2008/04/quality-is-not-accidental/ I'm -1 on a release without some RCs. On Thu, Dec 1, 2011 at 3:17 PM, John Casey jdca...@commonjava.org wrote: On 12/1/11 10:27 AM, Olivier Lamy wrote: 2011/12/1 Jörg Schaiblejoerg.schai...@scalaris.com: Benjamin Bentmann wrote: Olivier Lamy wrote: I'd like to release Apache Maven 3.0.4 (take 2). [...] Note the difference with first vote is an upgrade of aether to 1.13.1 What about the memory issue that Jörg brought up? Shouldn't we at least understand the cause and potential impact on other users before continuing the release? Continue, I'll report later, but it seems that there's no regression in 304 vs 303. Thanks! @Benjamin: I tend to say we must release it (maybe the famous early and often' :-) ). Early-and-often is great, but it's not an excuse to be lax on quality standards. Hudson had some famously horrible releases early on, and I suspect they had to do with sacrificing concerns about quality on the altar of early-and-often. An RC would take less than a week more if the code really is ready to go. If it's not, then we don't want to release it, do we? My goal is to provide a release point (stable tagged build) to get feedbacks. Trying to reach/wait the perfect release without those feedbacks is IMHO impossible. Actually it's not; the feedback comes by way of RCs. This is why it's so important to do RCs for Maven core. Maybe we can skip the RC process on plugins (I tend to think a single, quick RC is still a good idea there), but the core is far, far more complex. Even with a huge IT set we cannot hope to cover all use cases there, so it's simply not enough. If Jörg's issue doesn't pop up in this staged release, then I'd say let's just learn that lesson for next time. It takes a little longer using RCs, but it's the ONLY way we've been able to produce releases that weren't riddled with regressions in the past. Even with a strong IT suite, it's still good practice. As an aside, we might as well call this staging of 3.0.4 a RC and discuss it here as if it was. The main difference is procedural IMO, in that this is a [VOTE] thread, not a [DISCUSS] thread about whether the staged RC is ready to go. IMO that's an important distinction, since the 72h time limit is lurking nearby, but we'd still want to time-box the review of any RC The previous issue for ngnix users was blocker as some oss forge use it. So I cancel it and restart one (and thanks for the fast aether change). But for such memory issue at least users can change MAVEN_OPTS. My email [1] to Jörg describe various things to test on his private company build (I hope he will have time to provide such feedbacks with a stable maven build) Cheers, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail:
Re: [VOTE] Apache Maven 3.0.4 (take 2)
Thanks! It looks an erroneous file is picked when it has been download from a remote repo and when it's reinstall locally (use case of appassembler which reinstall file locally) investigating... 2011/12/3 Dan Tran dant...@gmail.com: here is sample pom.xml to reproduce the issue. 3.0.3 generate the correct lib dir, and script, but not 3.0.4 project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdmy.groupId/groupId artifactIdmyArtifactId/artifactId version1-SNAPSHOT/version packagingjar/packaging dependencies dependency groupIdcommons-cli/groupId artifactIdcommons-cli/artifactId version1.3-SNAPSHOT/version /dependency /dependencies build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdappassembler-maven-plugin/artifactId version1.1.1/version executions execution idgenerate-setup-scripts/id phaseprepare-package/phase goals goalassemble/goal /goals configuration repositoryLayoutflat/repositoryLayout generateRepositorytrue/generateRepository repositoryNamelib/repositoryName programs program mainClassfake.Main/mainClass namesetup/name /program /programs platforms platformunix/platform /platforms /configuration /execution /executions /plugin /plugins /build /project On Sat, Dec 3, 2011 at 8:42 AM, Brian Fox bri...@infinity.nu wrote: The RCs were started for a very specific reason, to improve the quality of our releases. Just breezing through this thread, there are clearly issues with memory and some other stuff here that may be bigger than we understand in this small testing surface. An RC build will get more eyes and either confirm these aren't a big deal, or they are. Reminder of where we were with 2.0.7, 2.0.8 and why we do RCs: http://www.sonatype.com/people/2008/04/quality-is-not-accidental/ I'm -1 on a release without some RCs. On Thu, Dec 1, 2011 at 3:17 PM, John Casey jdca...@commonjava.org wrote: On 12/1/11 10:27 AM, Olivier Lamy wrote: 2011/12/1 Jörg Schaiblejoerg.schai...@scalaris.com: Benjamin Bentmann wrote: Olivier Lamy wrote: I'd like to release Apache Maven 3.0.4 (take 2). [...] Note the difference with first vote is an upgrade of aether to 1.13.1 What about the memory issue that Jörg brought up? Shouldn't we at least understand the cause and potential impact on other users before continuing the release? Continue, I'll report later, but it seems that there's no regression in 304 vs 303. Thanks! @Benjamin: I tend to say we must release it (maybe the famous early and often' :-) ). Early-and-often is great, but it's not an excuse to be lax on quality standards. Hudson had some famously horrible releases early on, and I suspect they had to do with sacrificing concerns about quality on the altar of early-and-often. An RC would take less than a week more if the code really is ready to go. If it's not, then we don't want to release it, do we? My goal is to provide a release point (stable tagged build) to get feedbacks. Trying to reach/wait the perfect release without those feedbacks is IMHO impossible. Actually it's not; the feedback comes by way of RCs. This is why it's so important to do RCs for Maven core. Maybe we can skip the RC process on plugins (I tend to think a single, quick RC is still a good idea there), but the core is far, far more complex. Even with a huge IT set we cannot hope to cover all use cases there, so it's simply not enough. If Jörg's issue doesn't pop up in this staged release, then I'd say let's just learn that lesson for next time. It takes a little longer using RCs, but it's the ONLY way we've been able to produce releases that weren't riddled with regressions in the past. Even with a strong IT suite, it's still good practice. As an aside, we might as well call this staging of 3.0.4 a RC and discuss it here as if it was. The main difference is procedural IMO, in that this is a [VOTE] thread, not a [DISCUSS] thread about whether the staged RC is ready to go. IMO that's an important distinction, since the 72h time limit is lurking nearby, but we'd still want to time-box the review of any RC The previous issue for ngnix users was blocker as some oss forge use it. So I cancel it and restart one (and thanks for the fast aether change). But for such memory issue at least users can change MAVEN_OPTS. My email [1] to Jörg describe various things to test on his private company build (I hope he will have
Re: [VOTE] Apache Maven 3.0.4 (take 2)
Thanks for looking into this issue. consider it is a blocking regression since there is no work around for me to use 3.0.4 \-D On Sat, Dec 3, 2011 at 1:47 PM, Olivier Lamy ol...@apache.org wrote: Thanks! It looks an erroneous file is picked when it has been download from a remote repo and when it's reinstall locally (use case of appassembler which reinstall file locally) investigating... 2011/12/3 Dan Tran dant...@gmail.com: here is sample pom.xml to reproduce the issue. 3.0.3 generate the correct lib dir, and script, but not 3.0.4 project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdmy.groupId/groupId artifactIdmyArtifactId/artifactId version1-SNAPSHOT/version packagingjar/packaging dependencies dependency groupIdcommons-cli/groupId artifactIdcommons-cli/artifactId version1.3-SNAPSHOT/version /dependency /dependencies build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdappassembler-maven-plugin/artifactId version1.1.1/version executions execution idgenerate-setup-scripts/id phaseprepare-package/phase goals goalassemble/goal /goals configuration repositoryLayoutflat/repositoryLayout generateRepositorytrue/generateRepository repositoryNamelib/repositoryName programs program mainClassfake.Main/mainClass namesetup/name /program /programs platforms platformunix/platform /platforms /configuration /execution /executions /plugin /plugins /build /project On Sat, Dec 3, 2011 at 8:42 AM, Brian Fox bri...@infinity.nu wrote: The RCs were started for a very specific reason, to improve the quality of our releases. Just breezing through this thread, there are clearly issues with memory and some other stuff here that may be bigger than we understand in this small testing surface. An RC build will get more eyes and either confirm these aren't a big deal, or they are. Reminder of where we were with 2.0.7, 2.0.8 and why we do RCs: http://www.sonatype.com/people/2008/04/quality-is-not-accidental/ I'm -1 on a release without some RCs. On Thu, Dec 1, 2011 at 3:17 PM, John Casey jdca...@commonjava.org wrote: On 12/1/11 10:27 AM, Olivier Lamy wrote: 2011/12/1 Jörg Schaiblejoerg.schai...@scalaris.com: Benjamin Bentmann wrote: Olivier Lamy wrote: I'd like to release Apache Maven 3.0.4 (take 2). [...] Note the difference with first vote is an upgrade of aether to 1.13.1 What about the memory issue that Jörg brought up? Shouldn't we at least understand the cause and potential impact on other users before continuing the release? Continue, I'll report later, but it seems that there's no regression in 304 vs 303. Thanks! @Benjamin: I tend to say we must release it (maybe the famous early and often' :-) ). Early-and-often is great, but it's not an excuse to be lax on quality standards. Hudson had some famously horrible releases early on, and I suspect they had to do with sacrificing concerns about quality on the altar of early-and-often. An RC would take less than a week more if the code really is ready to go. If it's not, then we don't want to release it, do we? My goal is to provide a release point (stable tagged build) to get feedbacks. Trying to reach/wait the perfect release without those feedbacks is IMHO impossible. Actually it's not; the feedback comes by way of RCs. This is why it's so important to do RCs for Maven core. Maybe we can skip the RC process on plugins (I tend to think a single, quick RC is still a good idea there), but the core is far, far more complex. Even with a huge IT set we cannot hope to cover all use cases there, so it's simply not enough. If Jörg's issue doesn't pop up in this staged release, then I'd say let's just learn that lesson for next time. It takes a little longer using RCs, but it's the ONLY way we've been able to produce releases that weren't riddled with regressions in the past. Even with a strong IT suite, it's still good practice. As an aside, we might as well call this staging of 3.0.4 a RC and discuss it here as if it was. The main difference is procedural IMO, in that this is a [VOTE] thread, not a [DISCUSS] thread about whether the staged RC is ready to go. IMO that's an important distinction, since the 72h time limit is lurking nearby, but we'd still want to time-box the review of any RC The previous issue for ngnix users was blocker as some oss forge use it. So I cancel it and restart
Re: [VOTE] Apache Maven 3.0.4 (take 2)
+1 runs fine here, artifacts look good. LieGrue, strub - Original Message - From: Olivier Lamy ol...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Thursday, December 1, 2011 10:20 AM Subject: [VOTE] Apache Maven 3.0.4 (take 2) Hello, I'd like to release Apache Maven 3.0.4 (take 2). We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 Note the difference with first vote is an upgrade of aether to 1.13.1 (to prevent chuncked transfer encoding when deploying md5/sha1 files http(s): mode which is not supported by ngnix). And ref site (http://maven.apache.org/ref/3.0.4/) which now use the new fluido skin (wait sync). The staged repo is available here: https://repository.apache.org/content/repositories/maven-283/ The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote. [+1] [0] [-1] Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
+1 Kristian Den 01.12.2011 13:16, skrev Arnaud Héritier: +1 On Thu, Dec 1, 2011 at 12:48 PM, Anders Hammarand...@hammar.net wrote: +1 Checksums are now created correctly when deploying a snapshot to Codehaus's Nexus instance. /Anders On Thu, Dec 1, 2011 at 12:08, kreysseld...@kreyssel.org wrote: +1 -- View this message in context: http://maven.40175.n5.nabble.com/VOTE-Apache-Maven-3-0-4-take-2-tp5038109p5038345.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
+1 (non binding). Baptiste 2011/12/2 Kristian Rosenvold kristian.rosenv...@gmail.com +1 Kristian Den 01.12.2011 13:16, skrev Arnaud Héritier: +1 On Thu, Dec 1, 2011 at 12:48 PM, Anders Hammarand...@hammar.net wrote: +1 Checksums are now created correctly when deploying a snapshot to Codehaus's Nexus instance. /Anders On Thu, Dec 1, 2011 at 12:08, kreysseld...@kreyssel.org wrote: +1 -- View this message in context: http://maven.40175.n5.nabble.**com/VOTE-Apache-Maven-3-0-4-** take-2-tp5038109p5038345.htmlhttp://maven.40175.n5.nabble.com/VOTE-Apache-Maven-3-0-4-take-2-tp5038109p5038345.html Sent from the Maven Developers mailing list archive at Nabble.com. --**--** - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org --**--** - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: [VOTE] Apache Maven 3.0.4 (take 2)
On Thu, 1 Dec 2011 10:20:55 +0100 Olivier Lamy ol...@apache.org wrote: +1 since was ok to me (without the deploy bug) thanks, Tony (non-binding) Hello, I'd like to release Apache Maven 3.0.4 (take 2). We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 Note the difference with first vote is an upgrade of aether to 1.13.1 (to prevent chuncked transfer encoding when deploying md5/sha1 files http(s): mode which is not supported by ngnix). And ref site (http://maven.apache.org/ref/3.0.4/) which now use the new fluido skin (wait sync). The staged repo is available here: https://repository.apache.org/content/repositories/maven-283/ The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote. [+1] [0] [-1] Here my +1 Thanks, -- Tony Chemit tél: +33 (0) 2 40 50 29 28 email: che...@codelutin.com http://www.codelutin.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
+1 Been using it all day for a variety of things and haven't run into any issues. Dan On Thursday, December 01, 2011 10:20:55 AM Olivier Lamy wrote: Hello, I'd like to release Apache Maven 3.0.4 (take 2). We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=172 15 Note the difference with first vote is an upgrade of aether to 1.13.1 (to prevent chuncked transfer encoding when deploying md5/sha1 files http(s): mode which is not supported by ngnix). And ref site (http://maven.apache.org/ref/3.0.4/) which now use the new fluido skin (wait sync). The staged repo is available here: https://repository.apache.org/content/repositories/maven-283/ The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote. [+1] [0] [-1] Here my +1 Thanks, -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
I've done several medium sized builds and everything looks okay here. +1 On 12/1/11 4:20 AM, Olivier Lamy wrote: Hello, I'd like to release Apache Maven 3.0.4 (take 2). We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 Note the difference with first vote is an upgrade of aether to 1.13.1 (to prevent chuncked transfer encoding when deploying md5/sha1 files http(s): mode which is not supported by ngnix). And ref site (http://maven.apache.org/ref/3.0.4/) which now use the new fluido skin (wait sync). The staged repo is available here: https://repository.apache.org/content/repositories/maven-283/ The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote. [+1] [0] [-1] Here my +1 Thanks, -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
When using 3.0.4 with appassemble-maven-plugin to generate java wrapper scripts which use snapshot dependency. The plugin places the dependencies to its lib/repo directory using timestamp snapshots picked up from maven repo, but generated scripts using '-SNAPSHOT' for its classpath. this breaks my runtime. There is no issue with 3.0.3. Do others see the same issue? Thanks -D On Fri, Dec 2, 2011 at 12:39 PM, John Casey jdca...@commonjava.org wrote: I've done several medium sized builds and everything looks okay here. +1 On 12/1/11 4:20 AM, Olivier Lamy wrote: Hello, I'd like to release Apache Maven 3.0.4 (take 2). We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 Note the difference with first vote is an upgrade of aether to 1.13.1 (to prevent chuncked transfer encoding when deploying md5/sha1 files http(s): mode which is not supported by ngnix). And ref site (http://maven.apache.org/ref/3.0.4/) which now use the new fluido skin (wait sync). The staged repo is available here: https://repository.apache.org/content/repositories/maven-283/ The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote. [+1] [0] [-1] Here my +1 Thanks, -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
+1 Emmanuel On Thu, Dec 1, 2011 at 10:20 AM, Olivier Lamy ol...@apache.org wrote: Hello, I'd like to release Apache Maven 3.0.4 (take 2). We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 Note the difference with first vote is an upgrade of aether to 1.13.1 (to prevent chuncked transfer encoding when deploying md5/sha1 files http(s): mode which is not supported by ngnix). And ref site (http://maven.apache.org/ref/3.0.4/) which now use the new fluido skin (wait sync). The staged repo is available here: https://repository.apache.org/content/repositories/maven-283/ The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote. [+1] [0] [-1] Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
+1 (non-binding) used it on a couple of builds without problems. Regards Mirko -- Sent from my phone http://illegalstateexception.blogspot.com http://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ On Dec 3, 2011 2:33 AM, Emmanuel Venisse emmanuel.veni...@gmail.com wrote: +1 Emmanuel On Thu, Dec 1, 2011 at 10:20 AM, Olivier Lamy ol...@apache.org wrote: Hello, I'd like to release Apache Maven 3.0.4 (take 2). We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 Note the difference with first vote is an upgrade of aether to 1.13.1 (to prevent chuncked transfer encoding when deploying md5/sha1 files http(s): mode which is not supported by ngnix). And ref site (http://maven.apache.org/ref/3.0.4/) which now use the new fluido skin (wait sync). The staged repo is available here: https://repository.apache.org/content/repositories/maven-283/ The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote. [+1] [0] [-1] Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Apache Maven 3.0.4 (take 2)
Hello, I'd like to release Apache Maven 3.0.4 (take 2). We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 Note the difference with first vote is an upgrade of aether to 1.13.1 (to prevent chuncked transfer encoding when deploying md5/sha1 files http(s): mode which is not supported by ngnix). And ref site (http://maven.apache.org/ref/3.0.4/) which now use the new fluido skin (wait sync). The staged repo is available here: https://repository.apache.org/content/repositories/maven-283/ The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote. [+1] [0] [-1] Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
+1 -- View this message in context: http://maven.40175.n5.nabble.com/VOTE-Apache-Maven-3-0-4-take-2-tp5038109p5038345.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
+1 Checksums are now created correctly when deploying a snapshot to Codehaus's Nexus instance. /Anders On Thu, Dec 1, 2011 at 12:08, kreyssel d...@kreyssel.org wrote: +1 -- View this message in context: http://maven.40175.n5.nabble.com/VOTE-Apache-Maven-3-0-4-take-2-tp5038109p5038345.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
+1 On Thu, Dec 1, 2011 at 12:48 PM, Anders Hammar and...@hammar.net wrote: +1 Checksums are now created correctly when deploying a snapshot to Codehaus's Nexus instance. /Anders On Thu, Dec 1, 2011 at 12:08, kreyssel d...@kreyssel.org wrote: +1 -- View this message in context: http://maven.40175.n5.nabble.com/VOTE-Apache-Maven-3-0-4-take-2-tp5038109p5038345.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
Does no one else think it reasonable to do RCs like we have been doing for the last 2 years? On Dec 1, 2011, at 1:20 AM, Olivier Lamy wrote: Hello, I'd like to release Apache Maven 3.0.4 (take 2). We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 Note the difference with first vote is an upgrade of aether to 1.13.1 (to prevent chuncked transfer encoding when deploying md5/sha1 files http(s): mode which is not supported by ngnix). And ref site (http://maven.apache.org/ref/3.0.4/) which now use the new fluido skin (wait sync). The staged repo is available here: https://repository.apache.org/content/repositories/maven-283/ The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote. [+1] [0] [-1] Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
Re: [VOTE] Apache Maven 3.0.4 (take 2)
Olivier Lamy wrote: I'd like to release Apache Maven 3.0.4 (take 2). [...] Note the difference with first vote is an upgrade of aether to 1.13.1 What about the memory issue that Jörg brought up? Shouldn't we at least understand the cause and potential impact on other users before continuing the release? Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
sure why not for next one. 2011/12/1 Jason van Zyl ja...@tesla.io: Does no one else think it reasonable to do RCs like we have been doing for the last 2 years? On Dec 1, 2011, at 1:20 AM, Olivier Lamy wrote: Hello, I'd like to release Apache Maven 3.0.4 (take 2). We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 Note the difference with first vote is an upgrade of aether to 1.13.1 (to prevent chuncked transfer encoding when deploying md5/sha1 files http(s): mode which is not supported by ngnix). And ref site (http://maven.apache.org/ref/3.0.4/) which now use the new fluido skin (wait sync). The staged repo is available here: https://repository.apache.org/content/repositories/maven-283/ The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote. [+1] [0] [-1] Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
Benjamin Bentmann wrote: Olivier Lamy wrote: I'd like to release Apache Maven 3.0.4 (take 2). [...] Note the difference with first vote is an upgrade of aether to 1.13.1 What about the memory issue that Jörg brought up? Shouldn't we at least understand the cause and potential impact on other users before continuing the release? Continue, I'll report later, but it seems that there's no regression in 304 vs 303. Cheers, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
yes we should have done it... Lesson to learn for next releases ... On Thu, Dec 1, 2011 at 3:17 PM, Jason van Zyl ja...@tesla.io wrote: Does no one else think it reasonable to do RCs like we have been doing for the last 2 years? On Dec 1, 2011, at 1:20 AM, Olivier Lamy wrote: Hello, I'd like to release Apache Maven 3.0.4 (take 2). We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 Note the difference with first vote is an upgrade of aether to 1.13.1 (to prevent chuncked transfer encoding when deploying md5/sha1 files http(s): mode which is not supported by ngnix). And ref site (http://maven.apache.org/ref/3.0.4/) which now use the new fluido skin (wait sync). The staged repo is available here: https://repository.apache.org/content/repositories/maven-283/ The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote. [+1] [0] [-1] Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
Re: [VOTE] Apache Maven 3.0.4 (take 2)
2011/12/1 Jörg Schaible joerg.schai...@scalaris.com: Benjamin Bentmann wrote: Olivier Lamy wrote: I'd like to release Apache Maven 3.0.4 (take 2). [...] Note the difference with first vote is an upgrade of aether to 1.13.1 What about the memory issue that Jörg brought up? Shouldn't we at least understand the cause and potential impact on other users before continuing the release? Continue, I'll report later, but it seems that there's no regression in 304 vs 303. Thanks! @Benjamin: I tend to say we must release it (maybe the famous early and often' :-) ). My goal is to provide a release point (stable tagged build) to get feedbacks. Trying to reach/wait the perfect release without those feedbacks is IMHO impossible. The previous issue for ngnix users was blocker as some oss forge use it. So I cancel it and restart one (and thanks for the fast aether change). But for such memory issue at least users can change MAVEN_OPTS. My email [1] to Jörg describe various things to test on his private company build (I hope he will have time to provide such feedbacks with a stable maven build) Cheers, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy [1] http://markmail.org/message/wimu2bm3cfdp6kuh - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
Hi, Jörg Schaible wrote: Hi Oliver, Olivier Lamy wrote: @Jörg any open source projects you can share ? Sorry, no, but I am try some runs now on a dedicated build server ... a run takes some time though It took a while, because I was hit by a real M3 regression first: MNG-5207 However, after building anything once with M2, I was able to run M3 (even if it did not calculate the proper build order, but the local repo was stuffed). What kind of builds are you doing ? install deploy ? mvn clean install with an empty repo or an already populated one ? populated is there any reporting done (site plugin use) no The dedicated build server is of arch amd64 and as it turned out, the PermGen space consumption on that arch is even worse. Even with 256m PermGen space the build stops with an OOME: PermGen space after 45 of 417 projects. However, M303 and M304 behave *exactly* the same (multiple runs for each). Even for M221 the build stops now after 55 projects (but different build order compared to M30x). So the good news: No regression with M304. The bad news: Something consumes PermGen space meanwhile really fast. It might be as well one of the plugins that have been updated in the last 3 of 4 months :-/ ? etc... Any stack trace you could provide ? Perso, I have tested this build with asf projects with huge build (cxf and camel). Note my MAVEN_OPTS is export MAVEN_OPTS=-Djava.awt.headless=true -Xmx768m -Xms768m -XX:MaxPermSize=256m -client Mine are -Xmx1g -XX:MaxPermSize=144m. PermSize was chosen to allow such a build to succeed. Could you add -XX:+HeapDumpOnOutOfMemoryError in your MAVEN_OPTS ? (-XX:HeapDumpPath= to control the path where it's generated- Maybe this can help us to see what's the issue. OK, I try to repeat the situation first on the build server above. These are next actions ... [snip] - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
It's been so long I guess people have forgotten RCs used to be made. The release of Apache Maven itself is sufficiently different to just a plugin that a more formal release does make sense, but on the flip side after all the arguments trying to get this out I guess people just want it out there NOW. I'd like to see it out sooner than later myself - using the Sonatype RC build you published a few months ago revealed no egregious problems on my usage - but then that wasn't using the new Wagon... -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Fri, Dec 2, 2011 at 3:17 AM, Jason van Zyl ja...@tesla.io wrote: Does no one else think it reasonable to do RCs like we have been doing for the last 2 years? On Dec 1, 2011, at 1:20 AM, Olivier Lamy wrote: Hello, I'd like to release Apache Maven 3.0.4 (take 2). We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 Note the difference with first vote is an upgrade of aether to 1.13.1 (to prevent chuncked transfer encoding when deploying md5/sha1 files http(s): mode which is not supported by ngnix). And ref site (http://maven.apache.org/ref/3.0.4/) which now use the new fluido skin (wait sync). The staged repo is available here: https://repository.apache.org/content/repositories/maven-283/ The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote. [+1] [0] [-1] Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
Re: [VOTE] Apache Maven 3.0.4 (take 2)
+1 non-binding. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Thu, Dec 1, 2011 at 10:20 PM, Olivier Lamy ol...@apache.org wrote: Hello, I'd like to release Apache Maven 3.0.4 (take 2). We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 Note the difference with first vote is an upgrade of aether to 1.13.1 (to prevent chuncked transfer encoding when deploying md5/sha1 files http(s): mode which is not supported by ngnix). And ref site (http://maven.apache.org/ref/3.0.4/) which now use the new fluido skin (wait sync). The staged repo is available here: https://repository.apache.org/content/repositories/maven-283/ The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote. [+1] [0] [-1] Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
On 12/1/11 10:27 AM, Olivier Lamy wrote: 2011/12/1 Jörg Schaiblejoerg.schai...@scalaris.com: Benjamin Bentmann wrote: Olivier Lamy wrote: I'd like to release Apache Maven 3.0.4 (take 2). [...] Note the difference with first vote is an upgrade of aether to 1.13.1 What about the memory issue that Jörg brought up? Shouldn't we at least understand the cause and potential impact on other users before continuing the release? Continue, I'll report later, but it seems that there's no regression in 304 vs 303. Thanks! @Benjamin: I tend to say we must release it (maybe the famous early and often' :-) ). Early-and-often is great, but it's not an excuse to be lax on quality standards. Hudson had some famously horrible releases early on, and I suspect they had to do with sacrificing concerns about quality on the altar of early-and-often. An RC would take less than a week more if the code really is ready to go. If it's not, then we don't want to release it, do we? My goal is to provide a release point (stable tagged build) to get feedbacks. Trying to reach/wait the perfect release without those feedbacks is IMHO impossible. Actually it's not; the feedback comes by way of RCs. This is why it's so important to do RCs for Maven core. Maybe we can skip the RC process on plugins (I tend to think a single, quick RC is still a good idea there), but the core is far, far more complex. Even with a huge IT set we cannot hope to cover all use cases there, so it's simply not enough. If Jörg's issue doesn't pop up in this staged release, then I'd say let's just learn that lesson for next time. It takes a little longer using RCs, but it's the ONLY way we've been able to produce releases that weren't riddled with regressions in the past. Even with a strong IT suite, it's still good practice. As an aside, we might as well call this staging of 3.0.4 a RC and discuss it here as if it was. The main difference is procedural IMO, in that this is a [VOTE] thread, not a [DISCUSS] thread about whether the staged RC is ready to go. IMO that's an important distinction, since the 72h time limit is lurking nearby, but we'd still want to time-box the review of any RC The previous issue for ngnix users was blocker as some oss forge use it. So I cancel it and restart one (and thanks for the fast aether change). But for such memory issue at least users can change MAVEN_OPTS. My email [1] to Jörg describe various things to test on his private company build (I hope he will have time to provide such feedbacks with a stable maven build) Cheers, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
It seems to me that one of the major values of an 'RC' discipline is that it's uniquely tagged and bagged we can tell which bugs where found or fixed in which RC. This in turn could argue for a scheme in which we vote and release 'milestone' releases: available for general testing, protected by the Foundation's umbrella, but officially not fully stable. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
On 12/1/11 3:25 PM, Benson Margulies wrote: It seems to me that one of the major values of an 'RC' discipline is that it's uniquely tagged and bagged we can tell which bugs where found or fixed in which RC. This in turn could argue for a scheme in which we vote and release 'milestone' releases: available for general testing, protected by the Foundation's umbrella, but officially not fully stable. Based on long experience answering questions and criticism about this project, I've learned to be a little more cautious about calling something ready without having feedback from users. It's just my opinion, but it seems like soliciting feedback only after calling something released is a little back-to-front. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
rc release mode [was Re: [VOTE] Apache Maven 3.0.4 (take 2) ]
Please change subject thread for such discussion ! Again, I don't have issue with this RC mode and I will take care next time. -- Olivier go back to hack 2011/12/1 Benson Margulies bimargul...@gmail.com: It seems to me that one of the major values of an 'RC' discipline is that it's uniquely tagged and bagged we can tell which bugs where found or fixed in which RC. This in turn could argue for a scheme in which we vote and release 'milestone' releases: available for general testing, protected by the Foundation's umbrella, but officially not fully stable. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4 (take 2)
On 12/1/11 3:28 PM, John Casey wrote: On 12/1/11 3:25 PM, Benson Margulies wrote: It seems to me that one of the major values of an 'RC' discipline is that it's uniquely tagged and bagged we can tell which bugs where found or fixed in which RC. This in turn could argue for a scheme in which we vote and release 'milestone' releases: available for general testing, protected by the Foundation's umbrella, but officially not fully stable. Based on long experience answering questions and criticism about this project, I've learned to be a little more cautious about calling something ready without having feedback from users. It's just my opinion, but it seems like soliciting feedback only after calling something released is a little back-to-front. Okay, okay. :-) I agree that given a long enough vote time limit, and the assumption that you won't pursue feedback for the RC on us...@...and the idea that we don't really care which RC fixed this or that bug. Given all that, this thread is effectively the same as doing an RC. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: deprecate a method for wagon stream api (was Re: [VOTE] Apache Maven 3.0.4 )
Hello,
2011/11/30 Brett Porter br...@apache.org:
Note that it wasn't really called until r1179571, so I think maybe the
http-shared module should go back to not supporting it. I suppose that was
added for Aether, which in turn is no longer needed :)
While looking at that I noticed this code is probably being called for
anything using the new putFromStream:
FileOutputStream fos = null;
try
{
this.source = File.createTempFile( http-wagon., .tmp );
this.source.deleteOnExit();
fos = new FileOutputStream( this.source );
IOUtil.copy( stream, fos );
John authored this code a long time ago:
http://svn.apache.org/viewvc?view=revisionrevision=786701. I get the feeling
with your recent changes this hack might no longer be necessary.
Yup agree. I will try to remove that.
Finally, why do we still have both http-shared and http-shared4?
IMHO there is a design issue here (see WAGON-359), those two modules
have the same classes in the same package
(org.apache.maven.wagon.shared.http).
@mark any good reason for that ? :-)
As now there is nothing shared now, because dav jackrabbit use
httpclient3 and http wagon use httpcli4, those classes can move to
their own modules. Or at least the package in shared4 must be change!
For some backward comp, I tend to be for package rename and keep those
http-shared* modules in 2.x (and remove it in 3.x)
Others ?
- Brett
On 30/11/2011, at 12:59 AM, Olivier Lamy wrote:
2011/11/29 Benjamin Bentmann benjamin.bentm...@udo.edu:
Tamás Cservenák wrote:
Out of curiosity, why is chunked transfer encoding used to transfer
the few byte long SHA1 string?
https://issues.sonatype.org/browse/AETHER-128
many servers does not support it
completely...
Which suggests to deprecate the problematic method in the StreamingWagon
API.
Agree I will .
Benjamin
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
Hi, Olivier Lamy wrote: Hello, I'd like to release Apache Maven 3.0.4. We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 The staged repo is available here: https://repository.apache.org/content/repositories/maven-244/ . The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote (which is around 120 hours) [+1] [0] [-1] Here my +1 I tried the new version with our global build project, but it seems that the new version takes a lot more PermGen space than before. M303 could build all ~400 projects with 144MB PermGen space, but M304 bails out after building 2/3rd of the projects. Anyone else facing increased PermGen space consumption? - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
Now you mention it I have - but I've often seen some of our builds randomly blow out of memory during some of our tests so I can't confirm its M304 at fault or not. ( mind you - I was running Jason's Sonatype M304 dist before that so its possible its there among a number of the newer builds... -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Wed, Nov 30, 2011 at 9:41 PM, Jörg Schaible joerg.schai...@scalaris.comwrote: ~400 projects with 144MB PermGen space, but M304 bails out after building 2/3rd of the projects. Anyone else facing increased PermGen space consumption?
Re: [VOTE] Apache Maven 3.0.4
Did you verify that you're using all the same plugins/versions ? You might consider running something like jvisualvm attached to both 3.0.3 and 3.0.4 to see if your 3.0.3 build is just millimeters away from failing on permgen already ;) Kristian Den 30.11.2011 09:41, skrev Jörg Schaible: Hi, Olivier Lamy wrote: Hello, I'd like to release Apache Maven 3.0.4. We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 The staged repo is available here: https://repository.apache.org/content/repositories/maven-244/ . The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote (which is around 120 hours) [+1] [0] [-1] Here my +1 I tried the new version with our global build project, but it seems that the new version takes a lot more PermGen space than before. M303 could build all ~400 projects with 144MB PermGen space, but M304 bails out after building 2/3rd of the projects. Anyone else facing increased PermGen space consumption? - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
@Jörg any open source projects you can share ? What kind of builds are you doing ? install deploy ? with an empty repo or an already populated one ? is there any reporting done (site plugin use) ? etc... Any stack trace you could provide ? Perso, I have tested this build with asf projects with huge build (cxf and camel). Note my MAVEN_OPTS is export MAVEN_OPTS=-Djava.awt.headless=true -Xmx768m -Xms768m -XX:MaxPermSize=256m -client Could you add -XX:+HeapDumpOnOutOfMemoryError in your MAVEN_OPTS ? (-XX:HeapDumpPath= to control the path where it's generated- Maybe this can help us to see what's the issue. IMHO the reasons for that is probably in external libraries update, we did. Changes I see are in 3.0.4 from 3.0.3 * new wagon http: light one 1.0-beta-7 to http 2.1 * aether 1.11 to 1.13.1 * sisu-inject* 2.1.1 to 2.3.0 (with sisu-guice too 2.9.4 to 3.1.0) If you have a bit of time to play with changes back (one by one) to lib and test ? 2011/11/30 Kristian Rosenvold kristian.rosenv...@gmail.com: Did you verify that you're using all the same plugins/versions ? You might consider running something like jvisualvm attached to both 3.0.3 and 3.0.4 to see if your 3.0.3 build is just millimeters away from failing on permgen already ;) Kristian Den 30.11.2011 09:41, skrev Jörg Schaible: Hi, Olivier Lamy wrote: Hello, I'd like to release Apache Maven 3.0.4. We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 The staged repo is available here: https://repository.apache.org/content/repositories/maven-244/ . The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote (which is around 120 hours) [+1] [0] [-1] Here my +1 I tried the new version with our global build project, but it seems that the new version takes a lot more PermGen space than before. M303 could build all ~400 projects with 144MB PermGen space, but M304 bails out after building 2/3rd of the projects. Anyone else facing increased PermGen space consumption? - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
Hi Oliver, Olivier Lamy wrote: @Jörg any open source projects you can share ? Sorry, no, but I am try some runs now on a dedicated build server ... a run takes some time though What kind of builds are you doing ? install deploy ? mvn clean install with an empty repo or an already populated one ? populated is there any reporting done (site plugin use) no ? etc... Any stack trace you could provide ? Perso, I have tested this build with asf projects with huge build (cxf and camel). Note my MAVEN_OPTS is export MAVEN_OPTS=-Djava.awt.headless=true -Xmx768m -Xms768m -XX:MaxPermSize=256m -client Mine are -Xmx1g -XX:MaxPermSize=144m. PermSize was chosen to allow such a build to succeed. Could you add -XX:+HeapDumpOnOutOfMemoryError in your MAVEN_OPTS ? (-XX:HeapDumpPath= to control the path where it's generated- Maybe this can help us to see what's the issue. OK, I try to repeat the situation first on the build server above. IMHO the reasons for that is probably in external libraries update, we did. Changes I see are in 3.0.4 from 3.0.3 * new wagon http: light one 1.0-beta-7 to http 2.1 * aether 1.11 to 1.13.1 * sisu-inject* 2.1.1 to 2.3.0 (with sisu-guice too 2.9.4 to 3.1.0) If you have a bit of time to play with changes back (one by one) to lib and test ? When I have a stable environment for this :) 2011/11/30 Kristian Rosenvold kristian.rosenv...@gmail.com: Did you verify that you're using all the same plugins/versions ? All involved plugins are pinned in a global pluginMgmt section. You might consider running something like jvisualvm attached to both 3.0.3 and 3.0.4 to see if your 3.0.3 build is just millimeters away from failing on permgen already ;) I don't know about jvisualvm, but yes, the build with M303 will use nearly all of the 144m PermSpace. However, M304 runs out of resources after 66% of the involved projects. Just for the records: % === $ mvn --version Apache Maven 3.0.4 (r1206075; 2011-11-25 09:20:29+0100) Maven home: /usr/share/maven-bin-3.0 Java version: 1.6.0_29, vendor: Sun Microsystems Inc. Java home: /opt/sun-jdk-1.6.0.29/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.0.6-gentoo, arch: i386, family: unix % === - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
Just did a release of maven scm and md5/sha1 are there : https://repository.apache.org/content/repositories/maven-265/org/apache/maven/scm/maven-scm-api/1.6/ My env: mbp-olamy:scm olamy$ which mvn /Users/olamy/softs/maven/apache-maven-3.0.4/bin/mvn mbp-olamy:scm olamy$ env | grep MAVEN_OPTS MAVEN_OPTS=-Djava.awt.headless=true -Xmx768m -Xms768m -XX:MaxPermSize=256m -client mbp-olamy:scm olamy$ mvn -v Apache Maven 3.0.4 (r1206075; 2011-11-25 09:20:29+0100) Maven home: /Users/olamy/softs/maven/apache-maven-3.0.4 Java version: 1.6.0_29, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: fr_FR, platform encoding: MacRoman OS name: mac os x, version: 10.7.2, arch: x86_64, family: mac So even I don't like that, I will probably release even with a -1 in the vote thread. Someone else reproduce that ? 2011/11/28 Stephen Connolly stephen.alan.conno...@gmail.com: I will check again tomorrow AM... but no extensions only depend on oss version 7 here is the project https://github.com/stephenc/high-scale-lib and benjamin, here is the unclosed staging repo: com.github.stephenc-299 On 28 November 2011 22:53, Olivier Lamy ol...@apache.org wrote: 2011/11/28 Benjamin Bentmann benjamin.bentm...@udo.edu: Stephen Connolly wrote: I just tried deploying to oss.sonatype.org and with the staged 3.0.4 there were no .md5's or .sha1's deployed to the staging repo Sounds like http://jira.codehaus.org/browse/WAGON-353, so maybe double-check that you don't have that wagon version in there as some extension or plugin dependency. Yup agree wagon release was only for this issue. And frankly I have build the current release with a 3.0.4 build. And md5 are there. https://repository.apache.org/content/repositories/maven-244/org/apache/maven/maven-core/3.0.4/ Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
Just tried a deploy @ mojo and having the same issue I'll try for a minimal pom on local file system, see how that goes On 29 November 2011 08:44, Olivier Lamy ol...@apache.org wrote: Just did a release of maven scm and md5/sha1 are there : https://repository.apache.org/content/repositories/maven-265/org/apache/maven/scm/maven-scm-api/1.6/ My env: mbp-olamy:scm olamy$ which mvn /Users/olamy/softs/maven/apache-maven-3.0.4/bin/mvn mbp-olamy:scm olamy$ env | grep MAVEN_OPTS MAVEN_OPTS=-Djava.awt.headless=true -Xmx768m -Xms768m -XX:MaxPermSize=256m -client mbp-olamy:scm olamy$ mvn -v Apache Maven 3.0.4 (r1206075; 2011-11-25 09:20:29+0100) Maven home: /Users/olamy/softs/maven/apache-maven-3.0.4 Java version: 1.6.0_29, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: fr_FR, platform encoding: MacRoman OS name: mac os x, version: 10.7.2, arch: x86_64, family: mac So even I don't like that, I will probably release even with a -1 in the vote thread. Someone else reproduce that ? 2011/11/28 Stephen Connolly stephen.alan.conno...@gmail.com: I will check again tomorrow AM... but no extensions only depend on oss version 7 here is the project https://github.com/stephenc/high-scale-lib and benjamin, here is the unclosed staging repo: com.github.stephenc-299 On 28 November 2011 22:53, Olivier Lamy ol...@apache.org wrote: 2011/11/28 Benjamin Bentmann benjamin.bentm...@udo.edu: Stephen Connolly wrote: I just tried deploying to oss.sonatype.org and with the staged 3.0.4 there were no .md5's or .sha1's deployed to the staging repo Sounds like http://jira.codehaus.org/browse/WAGON-353, so maybe double-check that you don't have that wagon version in there as some extension or plugin dependency. Yup agree wagon release was only for this issue. And frankly I have build the current release with a 3.0.4 build. And md5 are there. https://repository.apache.org/content/repositories/maven-244/org/apache/maven/maven-core/3.0.4/ Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
OK, just tried a simple deploy using a file: based wagon with the staged artifacts... [stephenc@stephenc ~]$ md5 ~/Downloads/apache-maven-3.0.4-bin.tar.gz MD5 (/Users/stephenc/Downloads/apache-maven-3.0.4-bin.tar.gz) = c1e67c7f32929b428266c88f7f62bee4 [stephenc@stephenc ~]$ tar -xzvf ~/Downloads/apache-maven-3.0.4-bin.tar.gz x apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar x apache-maven-3.0.4/lib/maven-embedder-3.0.4.jar x apache-maven-3.0.4/lib/maven-settings-3.0.4.jar x apache-maven-3.0.4/lib/plexus-utils-2.0.6.jar x apache-maven-3.0.4/lib/maven-core-3.0.4.jar x apache-maven-3.0.4/lib/maven-model-3.0.4.jar x apache-maven-3.0.4/lib/maven-settings-builder-3.0.4.jar x apache-maven-3.0.4/lib/plexus-interpolation-1.14.jar x apache-maven-3.0.4/lib/plexus-component-annotations-1.5.5.jar x apache-maven-3.0.4/lib/plexus-sec-dispatcher-1.3.jar x apache-maven-3.0.4/lib/plexus-cipher-1.7.jar x apache-maven-3.0.4/lib/maven-repository-metadata-3.0.4.jar x apache-maven-3.0.4/lib/maven-artifact-3.0.4.jar x apache-maven-3.0.4/lib/maven-plugin-api-3.0.4.jar x apache-maven-3.0.4/lib/sisu-inject-plexus-2.3.0.jar x apache-maven-3.0.4/lib/sisu-inject-bean-2.3.0.jar x apache-maven-3.0.4/lib/sisu-guice-3.1.0-no_aop.jar x apache-maven-3.0.4/lib/sisu-guava-0.9.9.jar x apache-maven-3.0.4/lib/maven-model-builder-3.0.4.jar x apache-maven-3.0.4/lib/maven-aether-provider-3.0.4.jar x apache-maven-3.0.4/lib/aether-api-1.13.jar x apache-maven-3.0.4/lib/aether-spi-1.13.jar x apache-maven-3.0.4/lib/aether-util-1.13.jar x apache-maven-3.0.4/lib/aether-impl-1.13.jar x apache-maven-3.0.4/lib/maven-compat-3.0.4.jar x apache-maven-3.0.4/lib/wagon-provider-api-2.1.jar x apache-maven-3.0.4/lib/commons-cli-1.2.jar x apache-maven-3.0.4/lib/wagon-http-2.1-shaded.jar x apache-maven-3.0.4/lib/wagon-file-2.1.jar x apache-maven-3.0.4/lib/aether-connector-wagon-1.13.jar x apache-maven-3.0.4/LICENSE.txt x apache-maven-3.0.4/NOTICE.txt x apache-maven-3.0.4/README.txt x apache-maven-3.0.4/bin/m2.conf x apache-maven-3.0.4/bin/mvn.bat x apache-maven-3.0.4/bin/mvnDebug.bat x apache-maven-3.0.4/bin/mvn x apache-maven-3.0.4/bin/mvnDebug x apache-maven-3.0.4/bin/mvnyjp x apache-maven-3.0.4/conf/ x apache-maven-3.0.4/conf/settings.xml x apache-maven-3.0.4/lib/ x apache-maven-3.0.4/lib/ext/ x apache-maven-3.0.4/lib/ext/README.txt [stephenc@stephenc ~]$ export MAVEN_HOME=~/apache-maven-3.0.4 [stephenc@stephenc ~]$ export PATH=$MAVEN_HOME/bin:$PATH [stephenc@stephenc ~]$ mvn -version Apache Maven 3.0.4 (r1206075; 2011-11-25 08:20:29+) Maven home: /Users/stephenc/apache-maven-3.0.4 Java version: 1.6.0_29, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x, version: 10.6.8, arch: x86_64, family: mac [stephenc@stephenc ~]$ find file-repo file-repo [stephenc@stephenc ~]$ mvn deploy:deploy-file -Dfile=readme.txt -Durl=file:///Users/stephenc/file-repo/ -Dversion=1.0 -DgroupId=foo -DartifactId=bar -Dpackaging=txt [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building Maven Stub Project (No POM) 1 [INFO] [INFO] [INFO] --- maven-deploy-plugin:2.7:deploy-file (default-cli) @ standalone-pom --- Uploading: file:///Users/stephenc/file-repo/foo/bar/1.0/bar-1.0.txt Uploaded: file:///Users/stephenc/file-repo/foo/bar/1.0/bar-1.0.txt (7 B at 1.1 KB/sec) Uploading: file:///Users/stephenc/file-repo/foo/bar/1.0/bar-1.0.pom Uploaded: file:///Users/stephenc/file-repo/foo/bar/1.0/bar-1.0.pom (406 B at 396.5 KB/sec) Downloading: file:///Users/stephenc/file-repo/foo/bar/maven-metadata.xml Uploading: file:///Users/stephenc/file-repo/foo/bar/maven-metadata.xml Uploaded: file:///Users/stephenc/file-repo/foo/bar/maven-metadata.xml (282 B at 275.4 KB/sec) [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 0.553s [INFO] Finished at: Tue Nov 29 09:29:14 GMT 2011 [INFO] Final Memory: 3M/81M [INFO] [stephenc@stephenc ~]$ find file-repofile-repo file-repo/foo file-repo/foo/bar file-repo/foo/bar/1.0 file-repo/foo/bar/1.0/bar-1.0.pom file-repo/foo/bar/1.0/bar-1.0.pom.md5 file-repo/foo/bar/1.0/bar-1.0.pom.sha1 file-repo/foo/bar/1.0/bar-1.0.txt file-repo/foo/bar/1.0/bar-1.0.txt.md5 file-repo/foo/bar/1.0/bar-1.0.txt.sha1 file-repo/foo/bar/maven-metadata.xml file-repo/foo/bar/maven-metadata.xml.md5 file-repo/foo/bar/maven-metadata.xml.sha1 [stephenc@stephenc ~]$ The metadata is there so there may be something wrong with some of the forges' parent poms and wagon 2.1 as I had lack of md5's and sha1's when
Re: [VOTE] Apache Maven 3.0.4
hi Stephen! I did a local install of Apache MyFaces-2.1.6 to a private Nexus and I got the md5 and sha1 Just to be sure: are you really looking under 'browse storage', because 'browse index' doesn't show md5 and sha1 at all? txs and LieGrue, strub - Original Message - From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Tuesday, November 29, 2011 10:21 AM Subject: Re: [VOTE] Apache Maven 3.0.4 Just tried a deploy @ mojo and having the same issue I'll try for a minimal pom on local file system, see how that goes On 29 November 2011 08:44, Olivier Lamy ol...@apache.org wrote: Just did a release of maven scm and md5/sha1 are there : https://repository.apache.org/content/repositories/maven-265/org/apache/maven/scm/maven-scm-api/1.6/ My env: mbp-olamy:scm olamy$ which mvn /Users/olamy/softs/maven/apache-maven-3.0.4/bin/mvn mbp-olamy:scm olamy$ env | grep MAVEN_OPTS MAVEN_OPTS=-Djava.awt.headless=true -Xmx768m -Xms768m -XX:MaxPermSize=256m -client mbp-olamy:scm olamy$ mvn -v Apache Maven 3.0.4 (r1206075; 2011-11-25 09:20:29+0100) Maven home: /Users/olamy/softs/maven/apache-maven-3.0.4 Java version: 1.6.0_29, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: fr_FR, platform encoding: MacRoman OS name: mac os x, version: 10.7.2, arch: x86_64, family: mac So even I don't like that, I will probably release even with a -1 in the vote thread. Someone else reproduce that ? 2011/11/28 Stephen Connolly stephen.alan.conno...@gmail.com: I will check again tomorrow AM... but no extensions only depend on oss version 7 here is the project https://github.com/stephenc/high-scale-lib and benjamin, here is the unclosed staging repo: com.github.stephenc-299 On 28 November 2011 22:53, Olivier Lamy ol...@apache.org wrote: 2011/11/28 Benjamin Bentmann benjamin.bentm...@udo.edu: Stephen Connolly wrote: I just tried deploying to oss.sonatype.org and with the staged 3.0.4 there were no .md5's or .sha1's deployed to the staging repo Sounds like http://jira.codehaus.org/browse/WAGON-353, so maybe double-check that you don't have that wagon version in there as some extension or plugin dependency. Yup agree wagon release was only for this issue. And frankly I have build the current release with a 3.0.4 build. And md5 are there. https://repository.apache.org/content/repositories/maven-244/org/apache/maven/maven-core/3.0.4/ Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
I have side-by side staging repos with 3.0.3 and 3.0.4, the only change between them was MAVEN_HOME 3.0.3 has the md5's 3.0.4 doesn't for the exact same screen, and oss.sonatype.org refused to close the 3.0.4 deployed release last night because its validation failed due to missing md5's On 29 November 2011 09:37, Mark Struberg strub...@yahoo.de wrote: hi Stephen! I did a local install of Apache MyFaces-2.1.6 to a private Nexus and I got the md5 and sha1 Just to be sure: are you really looking under 'browse storage', because 'browse index' doesn't show md5 and sha1 at all? txs and LieGrue, strub - Original Message - From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Tuesday, November 29, 2011 10:21 AM Subject: Re: [VOTE] Apache Maven 3.0.4 Just tried a deploy @ mojo and having the same issue I'll try for a minimal pom on local file system, see how that goes On 29 November 2011 08:44, Olivier Lamy ol...@apache.org wrote: Just did a release of maven scm and md5/sha1 are there : https://repository.apache.org/content/repositories/maven-265/org/apache/maven/scm/maven-scm-api/1.6/ My env: mbp-olamy:scm olamy$ which mvn /Users/olamy/softs/maven/apache-maven-3.0.4/bin/mvn mbp-olamy:scm olamy$ env | grep MAVEN_OPTS MAVEN_OPTS=-Djava.awt.headless=true -Xmx768m -Xms768m -XX:MaxPermSize=256m -client mbp-olamy:scm olamy$ mvn -v Apache Maven 3.0.4 (r1206075; 2011-11-25 09:20:29+0100) Maven home: /Users/olamy/softs/maven/apache-maven-3.0.4 Java version: 1.6.0_29, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: fr_FR, platform encoding: MacRoman OS name: mac os x, version: 10.7.2, arch: x86_64, family: mac So even I don't like that, I will probably release even with a -1 in the vote thread. Someone else reproduce that ? 2011/11/28 Stephen Connolly stephen.alan.conno...@gmail.com: I will check again tomorrow AM... but no extensions only depend on oss version 7 here is the project https://github.com/stephenc/high-scale-lib and benjamin, here is the unclosed staging repo: com.github.stephenc-299 On 28 November 2011 22:53, Olivier Lamy ol...@apache.org wrote: 2011/11/28 Benjamin Bentmann benjamin.bentm...@udo.edu: Stephen Connolly wrote: I just tried deploying to oss.sonatype.org and with the staged 3.0.4 there were no .md5's or .sha1's deployed to the staging repo Sounds like http://jira.codehaus.org/browse/WAGON-353, so maybe double-check that you don't have that wagon version in there as some extension or plugin dependency. Yup agree wagon release was only for this issue. And frankly I have build the current release with a 3.0.4 build. And md5 are there. https://repository.apache.org/content/repositories/maven-244/org/apache/maven/maven-core/3.0.4/ Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
Attached are screenshots of a more recent example On 29 November 2011 09:44, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I have side-by side staging repos with 3.0.3 and 3.0.4, the only change between them was MAVEN_HOME 3.0.3 has the md5's 3.0.4 doesn't for the exact same screen, and oss.sonatype.org refused to close the 3.0.4 deployed release last night because its validation failed due to missing md5's On 29 November 2011 09:37, Mark Struberg strub...@yahoo.de wrote: hi Stephen! I did a local install of Apache MyFaces-2.1.6 to a private Nexus and I got the md5 and sha1 Just to be sure: are you really looking under 'browse storage', because 'browse index' doesn't show md5 and sha1 at all? txs and LieGrue, strub - Original Message - From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Tuesday, November 29, 2011 10:21 AM Subject: Re: [VOTE] Apache Maven 3.0.4 Just tried a deploy @ mojo and having the same issue I'll try for a minimal pom on local file system, see how that goes On 29 November 2011 08:44, Olivier Lamy ol...@apache.org wrote: Just did a release of maven scm and md5/sha1 are there : https://repository.apache.org/content/repositories/maven-265/org/apache/maven/scm/maven-scm-api/1.6/ My env: mbp-olamy:scm olamy$ which mvn /Users/olamy/softs/maven/apache-maven-3.0.4/bin/mvn mbp-olamy:scm olamy$ env | grep MAVEN_OPTS MAVEN_OPTS=-Djava.awt.headless=true -Xmx768m -Xms768m -XX:MaxPermSize=256m -client mbp-olamy:scm olamy$ mvn -v Apache Maven 3.0.4 (r1206075; 2011-11-25 09:20:29+0100) Maven home: /Users/olamy/softs/maven/apache-maven-3.0.4 Java version: 1.6.0_29, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: fr_FR, platform encoding: MacRoman OS name: mac os x, version: 10.7.2, arch: x86_64, family: mac So even I don't like that, I will probably release even with a -1 in the vote thread. Someone else reproduce that ? 2011/11/28 Stephen Connolly stephen.alan.conno...@gmail.com: I will check again tomorrow AM... but no extensions only depend on oss version 7 here is the project https://github.com/stephenc/high-scale-lib and benjamin, here is the unclosed staging repo: com.github.stephenc-299 On 28 November 2011 22:53, Olivier Lamy ol...@apache.org wrote: 2011/11/28 Benjamin Bentmann benjamin.bentm...@udo.edu: Stephen Connolly wrote: I just tried deploying to oss.sonatype.org and with the staged 3.0.4 there were no .md5's or .sha1's deployed to the staging repo Sounds like http://jira.codehaus.org/browse/WAGON-353, so maybe double-check that you don't have that wagon version in there as some extension or plugin dependency. Yup agree wagon release was only for this issue. And frankly I have build the current release with a 3.0.4 build. And md5 are there. https://repository.apache.org/content/repositories/maven-244/org/apache/maven/maven-core/3.0.4/ Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
for got to mention On 29 November 2011 09:44, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I have side-by side staging repos with 3.0.3 and 3.0.4, the only change between them was MAVEN_HOME and PATH 3.0.3 has the md5's 3.0.4 doesn't for the exact same screen, and oss.sonatype.org refused to close the 3.0.4 deployed release last night because its validation failed due to missing md5's On 29 November 2011 09:37, Mark Struberg strub...@yahoo.de wrote: hi Stephen! I did a local install of Apache MyFaces-2.1.6 to a private Nexus and I got the md5 and sha1 Just to be sure: are you really looking under 'browse storage', because 'browse index' doesn't show md5 and sha1 at all? txs and LieGrue, strub - Original Message - From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Tuesday, November 29, 2011 10:21 AM Subject: Re: [VOTE] Apache Maven 3.0.4 Just tried a deploy @ mojo and having the same issue I'll try for a minimal pom on local file system, see how that goes On 29 November 2011 08:44, Olivier Lamy ol...@apache.org wrote: Just did a release of maven scm and md5/sha1 are there : https://repository.apache.org/content/repositories/maven-265/org/apache/maven/scm/maven-scm-api/1.6/ My env: mbp-olamy:scm olamy$ which mvn /Users/olamy/softs/maven/apache-maven-3.0.4/bin/mvn mbp-olamy:scm olamy$ env | grep MAVEN_OPTS MAVEN_OPTS=-Djava.awt.headless=true -Xmx768m -Xms768m -XX:MaxPermSize=256m -client mbp-olamy:scm olamy$ mvn -v Apache Maven 3.0.4 (r1206075; 2011-11-25 09:20:29+0100) Maven home: /Users/olamy/softs/maven/apache-maven-3.0.4 Java version: 1.6.0_29, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: fr_FR, platform encoding: MacRoman OS name: mac os x, version: 10.7.2, arch: x86_64, family: mac So even I don't like that, I will probably release even with a -1 in the vote thread. Someone else reproduce that ? 2011/11/28 Stephen Connolly stephen.alan.conno...@gmail.com: I will check again tomorrow AM... but no extensions only depend on oss version 7 here is the project https://github.com/stephenc/high-scale-lib and benjamin, here is the unclosed staging repo: com.github.stephenc-299 On 28 November 2011 22:53, Olivier Lamy ol...@apache.org wrote: 2011/11/28 Benjamin Bentmann benjamin.bentm...@udo.edu: Stephen Connolly wrote: I just tried deploying to oss.sonatype.org and with the staged 3.0.4 there were no .md5's or .sha1's deployed to the staging repo Sounds like http://jira.codehaus.org/browse/WAGON-353, so maybe double-check that you don't have that wagon version in there as some extension or plugin dependency. Yup agree wagon release was only for this issue. And frankly I have build the current release with a 3.0.4 build. And md5 are there. https://repository.apache.org/content/repositories/maven-244/org/apache/maven/maven-core/3.0.4/ Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
@Stephen the issue was with wagon-http 2.0 see http://jira.codehaus.org/browse/WAGON-353 I will add a core it test which check deploy of sha1 and md5. 2011/11/29 Stephen Connolly stephen.alan.conno...@gmail.com: OK, just tried a simple deploy using a file: based wagon with the staged artifacts... [stephenc@stephenc ~]$ md5 ~/Downloads/apache-maven-3.0.4-bin.tar.gz MD5 (/Users/stephenc/Downloads/apache-maven-3.0.4-bin.tar.gz) = c1e67c7f32929b428266c88f7f62bee4 [stephenc@stephenc ~]$ tar -xzvf ~/Downloads/apache-maven-3.0.4-bin.tar.gz x apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar x apache-maven-3.0.4/lib/maven-embedder-3.0.4.jar x apache-maven-3.0.4/lib/maven-settings-3.0.4.jar x apache-maven-3.0.4/lib/plexus-utils-2.0.6.jar x apache-maven-3.0.4/lib/maven-core-3.0.4.jar x apache-maven-3.0.4/lib/maven-model-3.0.4.jar x apache-maven-3.0.4/lib/maven-settings-builder-3.0.4.jar x apache-maven-3.0.4/lib/plexus-interpolation-1.14.jar x apache-maven-3.0.4/lib/plexus-component-annotations-1.5.5.jar x apache-maven-3.0.4/lib/plexus-sec-dispatcher-1.3.jar x apache-maven-3.0.4/lib/plexus-cipher-1.7.jar x apache-maven-3.0.4/lib/maven-repository-metadata-3.0.4.jar x apache-maven-3.0.4/lib/maven-artifact-3.0.4.jar x apache-maven-3.0.4/lib/maven-plugin-api-3.0.4.jar x apache-maven-3.0.4/lib/sisu-inject-plexus-2.3.0.jar x apache-maven-3.0.4/lib/sisu-inject-bean-2.3.0.jar x apache-maven-3.0.4/lib/sisu-guice-3.1.0-no_aop.jar x apache-maven-3.0.4/lib/sisu-guava-0.9.9.jar x apache-maven-3.0.4/lib/maven-model-builder-3.0.4.jar x apache-maven-3.0.4/lib/maven-aether-provider-3.0.4.jar x apache-maven-3.0.4/lib/aether-api-1.13.jar x apache-maven-3.0.4/lib/aether-spi-1.13.jar x apache-maven-3.0.4/lib/aether-util-1.13.jar x apache-maven-3.0.4/lib/aether-impl-1.13.jar x apache-maven-3.0.4/lib/maven-compat-3.0.4.jar x apache-maven-3.0.4/lib/wagon-provider-api-2.1.jar x apache-maven-3.0.4/lib/commons-cli-1.2.jar x apache-maven-3.0.4/lib/wagon-http-2.1-shaded.jar x apache-maven-3.0.4/lib/wagon-file-2.1.jar x apache-maven-3.0.4/lib/aether-connector-wagon-1.13.jar x apache-maven-3.0.4/LICENSE.txt x apache-maven-3.0.4/NOTICE.txt x apache-maven-3.0.4/README.txt x apache-maven-3.0.4/bin/m2.conf x apache-maven-3.0.4/bin/mvn.bat x apache-maven-3.0.4/bin/mvnDebug.bat x apache-maven-3.0.4/bin/mvn x apache-maven-3.0.4/bin/mvnDebug x apache-maven-3.0.4/bin/mvnyjp x apache-maven-3.0.4/conf/ x apache-maven-3.0.4/conf/settings.xml x apache-maven-3.0.4/lib/ x apache-maven-3.0.4/lib/ext/ x apache-maven-3.0.4/lib/ext/README.txt [stephenc@stephenc ~]$ export MAVEN_HOME=~/apache-maven-3.0.4 [stephenc@stephenc ~]$ export PATH=$MAVEN_HOME/bin:$PATH [stephenc@stephenc ~]$ mvn -version Apache Maven 3.0.4 (r1206075; 2011-11-25 08:20:29+) Maven home: /Users/stephenc/apache-maven-3.0.4 Java version: 1.6.0_29, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x, version: 10.6.8, arch: x86_64, family: mac [stephenc@stephenc ~]$ find file-repo file-repo [stephenc@stephenc ~]$ mvn deploy:deploy-file -Dfile=readme.txt -Durl=file:///Users/stephenc/file-repo/ -Dversion=1.0 -DgroupId=foo -DartifactId=bar -Dpackaging=txt [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building Maven Stub Project (No POM) 1 [INFO] [INFO] [INFO] --- maven-deploy-plugin:2.7:deploy-file (default-cli) @ standalone-pom --- Uploading: file:///Users/stephenc/file-repo/foo/bar/1.0/bar-1.0.txt Uploaded: file:///Users/stephenc/file-repo/foo/bar/1.0/bar-1.0.txt (7 B at 1.1 KB/sec) Uploading: file:///Users/stephenc/file-repo/foo/bar/1.0/bar-1.0.pom Uploaded: file:///Users/stephenc/file-repo/foo/bar/1.0/bar-1.0.pom (406 B at 396.5 KB/sec) Downloading: file:///Users/stephenc/file-repo/foo/bar/maven-metadata.xml Uploading: file:///Users/stephenc/file-repo/foo/bar/maven-metadata.xml Uploaded: file:///Users/stephenc/file-repo/foo/bar/maven-metadata.xml (282 B at 275.4 KB/sec) [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 0.553s [INFO] Finished at: Tue Nov 29 09:29:14 GMT 2011 [INFO] Final Memory: 3M/81M [INFO] [stephenc@stephenc ~]$ find file-repofile-repo file-repo/foo file-repo/foo/bar file-repo/foo/bar/1.0 file-repo/foo/bar/1.0/bar-1.0.pom file-repo/foo/bar/1.0/bar-1.0.pom.md5 file-repo/foo/bar/1.0/bar-1.0.pom.sha1 file-repo/foo/bar/1.0/bar-1.0.txt file-repo/foo/bar/1.0/bar-1.0.txt.md5 file-repo/foo/bar/1.0/bar-1.0.txt.sha1 file-repo/foo/bar/maven-metadata.xml file-repo/foo/bar/maven-metadata.xml.md5
Re: [VOTE] Apache Maven 3.0.4
Even with a clean local repo, .md5's are still not being deployed for me... If this is an issue with the embedded WAGON (and it is looking like it could be) then I have to change my vote back negative -0.9 (binding) [DEBUG] Using connector WagonRepositoryConnector with priority 0 for https://nexus.codehaus.org/service/local/staging/deploy/maven2/ as stephenconnolly Uploading: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom [DEBUG] Failed to upload SHA-1 checksum for /Users/stephenc/codehaus/mrm/target/checkout/pom.xml: Failed to transfer file: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom.sha1. Return code is: 411, ReasonPhrase:Length Required. org.apache.maven.wagon.TransferFailedException: Failed to transfer file: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom.sha1. Return code is: 411, ReasonPhrase:Length Required. at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:586) at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:495) at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.putFromStream(AbstractHttpClientWagon.java:489) at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.putFromStream(AbstractHttpClientWagon.java:935) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksum(WagonRepositoryConnector.java:885) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksums(WagonRepositoryConnector.java:861) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:818) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:467) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:274) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:211) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:443) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:137) at org.apache.maven.plugin.deploy.AbstractDeployMojo.deploy(AbstractDeployMojo.java:167) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:149) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) [DEBUG] Failed to upload MD5 checksum for /Users/stephenc/codehaus/mrm/target/checkout/pom.xml: Failed to transfer file: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom.md5. Return code is: 411, ReasonPhrase:Length Required. org.apache.maven.wagon.TransferFailedException: Failed to transfer file: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom.md5. Return code is: 411, ReasonPhrase:Length Required. at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:586) at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:495) at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.putFromStream(AbstractHttpClientWagon.java:489) at
Re: [VOTE] Apache Maven 3.0.4
That stacktrace was with extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version2.1/version /extension /extensions in the pom... if I try extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version1.0/version /extension /extensions I get [DEBUG] Using connector WagonRepositoryConnector with priority 0 for https://nexus.codehaus.org/service/local/staging/deploy/maven2/ as stephenconnolly Uploading: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom Nov 29, 2011 10:06:08 AM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme INFO: basic authentication scheme selected [DEBUG] Failed to upload SHA-1 checksum for /Users/stephenc/codehaus/mrm/target/checkout/pom.xml: Should not be using the streaming wagon for HTTP PUT java.lang.IllegalStateException: Should not be using the streaming wagon for HTTP PUT at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillOutputData(AbstractHttpClientWagon.java:692) at org.apache.maven.wagon.StreamWagon.getOutputStream(StreamWagon.java:188) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:272) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:252) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksum(WagonRepositoryConnector.java:885) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksums(WagonRepositoryConnector.java:861) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:818) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:467) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:274) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:211) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:443) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:137) at org.apache.maven.plugin.deploy.AbstractDeployMojo.deploy(AbstractDeployMojo.java:167) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:149) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) And if I try without extensions [DEBUG] Failed to upload SHA-1 checksum for /Users/stephenc/codehaus/mrm/target/checkout/pom.xml: Failed to transfer file: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom.sha1. Return code is: 411, ReasonPhrase:Length Required. org.apache.maven.wagon.TransferFailedException: Failed to transfer file: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom.sha1. Return code is: 411, ReasonPhrase:Length Required. at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:586) at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:495) at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.putFromStream(AbstractHttpClientWagon.java:489) at
Re: [VOTE] Apache Maven 3.0.4
I see the same checksum issue when trying to deploy a snapshot over at Codehaus mojo: https://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/mojo/jboss-packaging-maven-plugin/2.3-SNAPSHOT/ I'm changing my vote to -1 (non-binding). IMHO we do not want end user issues due to something like this. /Anders On Tue, Nov 29, 2011 at 11:09, Stephen Connolly stephen.alan.conno...@gmail.com wrote: That stacktrace was with extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version2.1/version /extension /extensions in the pom... if I try extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version1.0/version /extension /extensions I get [DEBUG] Using connector WagonRepositoryConnector with priority 0 for https://nexus.codehaus.org/service/local/staging/deploy/maven2/ as stephenconnolly Uploading: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom Nov 29, 2011 10:06:08 AM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme INFO: basic authentication scheme selected [DEBUG] Failed to upload SHA-1 checksum for /Users/stephenc/codehaus/mrm/target/checkout/pom.xml: Should not be using the streaming wagon for HTTP PUT java.lang.IllegalStateException: Should not be using the streaming wagon for HTTP PUT at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillOutputData(AbstractHttpClientWagon.java:692) at org.apache.maven.wagon.StreamWagon.getOutputStream(StreamWagon.java:188) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:272) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:252) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksum(WagonRepositoryConnector.java:885) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksums(WagonRepositoryConnector.java:861) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:818) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:467) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:274) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:211) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:443) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:137) at org.apache.maven.plugin.deploy.AbstractDeployMojo.deploy(AbstractDeployMojo.java:167) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:149) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) And if I try without extensions [DEBUG] Failed to upload SHA-1 checksum for /Users/stephenc/codehaus/mrm/target/checkout/pom.xml: Failed to transfer file: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom.sha1. Return code is: 411, ReasonPhrase:Length Required. org.apache.maven.wagon.TransferFailedException: Failed to transfer file:
Re: [VOTE] Apache Maven 3.0.4
I think delivering artifacts without md5 and sha1 is pretty much a blocker as this might introduce security issues along the line. So I'd say we investigate further before we go ahead. Thus I change my vote to a -1 (binding) also. We now have a few cases which work well and a few cases which cause this error. Means we have to check where the difference is. LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org Cc: Sent: Tuesday, November 29, 2011 11:14 AM Subject: Re: [VOTE] Apache Maven 3.0.4 I see the same checksum issue when trying to deploy a snapshot over at Codehaus mojo: https://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/mojo/jboss-packaging-maven-plugin/2.3-SNAPSHOT/ I'm changing my vote to -1 (non-binding). IMHO we do not want end user issues due to something like this. /Anders On Tue, Nov 29, 2011 at 11:09, Stephen Connolly stephen.alan.conno...@gmail.com wrote: That stacktrace was with extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version2.1/version /extension /extensions in the pom... if I try extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version1.0/version /extension /extensions I get [DEBUG] Using connector WagonRepositoryConnector with priority 0 for https://nexus.codehaus.org/service/local/staging/deploy/maven2/ as stephenconnolly Uploading: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom Nov 29, 2011 10:06:08 AM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme INFO: basic authentication scheme selected [DEBUG] Failed to upload SHA-1 checksum for /Users/stephenc/codehaus/mrm/target/checkout/pom.xml: Should not be using the streaming wagon for HTTP PUT java.lang.IllegalStateException: Should not be using the streaming wagon for HTTP PUT at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillOutputData(AbstractHttpClientWagon.java:692) at org.apache.maven.wagon.StreamWagon.getOutputStream(StreamWagon.java:188) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:272) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:252) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksum(WagonRepositoryConnector.java:885) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksums(WagonRepositoryConnector.java:861) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:818) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:467) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:274) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:211) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:443) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:137) at org.apache.maven.plugin.deploy.AbstractDeployMojo.deploy(AbstractDeployMojo.java:167) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:149) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597
Re: [VOTE] Apache Maven 3.0.4
Olivier Lamy wrote: I will add a core it test which check deploy of sha1 and md5. You might want to check MavenITmng4235HttpAuthDeploymentChecksumsTest before. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
Agree I will cancel the vote to investigate more. I wonder why it works when deploying maven scm to repository.apache.org and tested on a locally installed nexus instance ? Can nexus folks who are listening here explains to me in which case this happen http Return code: 411, ReasonPhrase:Length Required. Bad or empty Content-Length http header ? 2011/11/29 Mark Struberg strub...@yahoo.de: I think delivering artifacts without md5 and sha1 is pretty much a blocker as this might introduce security issues along the line. So I'd say we investigate further before we go ahead. Thus I change my vote to a -1 (binding) also. We now have a few cases which work well and a few cases which cause this error. Means we have to check where the difference is. LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org Cc: Sent: Tuesday, November 29, 2011 11:14 AM Subject: Re: [VOTE] Apache Maven 3.0.4 I see the same checksum issue when trying to deploy a snapshot over at Codehaus mojo: https://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/mojo/jboss-packaging-maven-plugin/2.3-SNAPSHOT/ I'm changing my vote to -1 (non-binding). IMHO we do not want end user issues due to something like this. /Anders On Tue, Nov 29, 2011 at 11:09, Stephen Connolly stephen.alan.conno...@gmail.com wrote: That stacktrace was with extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version2.1/version /extension /extensions in the pom... if I try extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version1.0/version /extension /extensions I get [DEBUG] Using connector WagonRepositoryConnector with priority 0 for https://nexus.codehaus.org/service/local/staging/deploy/maven2/ as stephenconnolly Uploading: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom Nov 29, 2011 10:06:08 AM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme INFO: basic authentication scheme selected [DEBUG] Failed to upload SHA-1 checksum for /Users/stephenc/codehaus/mrm/target/checkout/pom.xml: Should not be using the streaming wagon for HTTP PUT java.lang.IllegalStateException: Should not be using the streaming wagon for HTTP PUT at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillOutputData(AbstractHttpClientWagon.java:692) at org.apache.maven.wagon.StreamWagon.getOutputStream(StreamWagon.java:188) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:272) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:252) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksum(WagonRepositoryConnector.java:885) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksums(WagonRepositoryConnector.java:861) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:818) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:467) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:274) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:211) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:443) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:137) at org.apache.maven.plugin.deploy.AbstractDeployMojo.deploy(AbstractDeployMojo.java:167) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:149) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196
Re: [VOTE] Apache Maven 3.0.4
2011/11/29 Benjamin Bentmann benjamin.bentm...@udo.edu: Olivier Lamy wrote: I will add a core it test which check deploy of sha1 and md5. You might want to check MavenITmng4235HttpAuthDeploymentChecksumsTest before. Thanks. And btw this it pass well :-) Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[CANCEL VOTE] Apache Maven 3.0.4
So due to issues when releasing project and missing md5/sha1 on some env whereas not on other. The vote is cancelled for more investigations. 2011/11/25 Olivier Lamy ol...@apache.org: Hello, I'd like to release Apache Maven 3.0.4. We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 The staged repo is available here: https://repository.apache.org/content/repositories/maven-244/ . The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote (which is around 120 hours) [+1] [0] [-1] Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
Hi, Nexus does not respond with HTTP 411. It has to be some nexus-fronting app (httpd or nginx?) And I am 99% confident that according to RFC[1], this was a case of incomplete request or such. As I inspected, nexus@codehaus is fronted by nginx 0.8.24 By googling, I found this: http://www.lamnk.com/blog/computer/fix-nginx-411-length-required-error/ [1] http://tools.ietf.org/html/rfc2616 Thanks, ~t~ On Tue, Nov 29, 2011 at 12:35 PM, Olivier Lamy ol...@apache.org wrote: Agree I will cancel the vote to investigate more. I wonder why it works when deploying maven scm to repository.apache.org and tested on a locally installed nexus instance ? Can nexus folks who are listening here explains to me in which case this happen http Return code: 411, ReasonPhrase:Length Required. Bad or empty Content-Length http header ? 2011/11/29 Mark Struberg strub...@yahoo.de: I think delivering artifacts without md5 and sha1 is pretty much a blocker as this might introduce security issues along the line. So I'd say we investigate further before we go ahead. Thus I change my vote to a -1 (binding) also. We now have a few cases which work well and a few cases which cause this error. Means we have to check where the difference is. LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org Cc: Sent: Tuesday, November 29, 2011 11:14 AM Subject: Re: [VOTE] Apache Maven 3.0.4 I see the same checksum issue when trying to deploy a snapshot over at Codehaus mojo: https://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/mojo/jboss-packaging-maven-plugin/2.3-SNAPSHOT/ I'm changing my vote to -1 (non-binding). IMHO we do not want end user issues due to something like this. /Anders On Tue, Nov 29, 2011 at 11:09, Stephen Connolly stephen.alan.conno...@gmail.com wrote: That stacktrace was with extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version2.1/version /extension /extensions in the pom... if I try extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version1.0/version /extension /extensions I get [DEBUG] Using connector WagonRepositoryConnector with priority 0 for https://nexus.codehaus.org/service/local/staging/deploy/maven2/ as stephenconnolly Uploading: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom Nov 29, 2011 10:06:08 AM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme INFO: basic authentication scheme selected [DEBUG] Failed to upload SHA-1 checksum for /Users/stephenc/codehaus/mrm/target/checkout/pom.xml: Should not be using the streaming wagon for HTTP PUT java.lang.IllegalStateException: Should not be using the streaming wagon for HTTP PUT at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillOutputData(AbstractHttpClientWagon.java:692) at org.apache.maven.wagon.StreamWagon.getOutputStream(StreamWagon.java:188) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:272) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:252) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksum(WagonRepositoryConnector.java:885) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksums(WagonRepositoryConnector.java:861) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:818) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:467) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:274) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:211) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:443) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:137) at org.apache.maven.plugin.deploy.AbstractDeployMojo.deploy(AbstractDeployMojo.java:167) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:149) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59
Re: [VOTE] Apache Maven 3.0.4
Thanks. That's what I have seen. Content-Lenght is null because chunked is used. I will enhance core it to ensure Content-Length header is correct and update wagon http to fix that. BTW canceling a release because a http server does not support chunck is a pain 2011/11/29 Tamás Cservenák ta...@cservenak.net: Hi, Nexus does not respond with HTTP 411. It has to be some nexus-fronting app (httpd or nginx?) And I am 99% confident that according to RFC[1], this was a case of incomplete request or such. As I inspected, nexus@codehaus is fronted by nginx 0.8.24 By googling, I found this: http://www.lamnk.com/blog/computer/fix-nginx-411-length-required-error/ [1] http://tools.ietf.org/html/rfc2616 Thanks, ~t~ On Tue, Nov 29, 2011 at 12:35 PM, Olivier Lamy ol...@apache.org wrote: Agree I will cancel the vote to investigate more. I wonder why it works when deploying maven scm to repository.apache.org and tested on a locally installed nexus instance ? Can nexus folks who are listening here explains to me in which case this happen http Return code: 411, ReasonPhrase:Length Required. Bad or empty Content-Length http header ? 2011/11/29 Mark Struberg strub...@yahoo.de: I think delivering artifacts without md5 and sha1 is pretty much a blocker as this might introduce security issues along the line. So I'd say we investigate further before we go ahead. Thus I change my vote to a -1 (binding) also. We now have a few cases which work well and a few cases which cause this error. Means we have to check where the difference is. LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org Cc: Sent: Tuesday, November 29, 2011 11:14 AM Subject: Re: [VOTE] Apache Maven 3.0.4 I see the same checksum issue when trying to deploy a snapshot over at Codehaus mojo: https://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/mojo/jboss-packaging-maven-plugin/2.3-SNAPSHOT/ I'm changing my vote to -1 (non-binding). IMHO we do not want end user issues due to something like this. /Anders On Tue, Nov 29, 2011 at 11:09, Stephen Connolly stephen.alan.conno...@gmail.com wrote: That stacktrace was with extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version2.1/version /extension /extensions in the pom... if I try extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version1.0/version /extension /extensions I get [DEBUG] Using connector WagonRepositoryConnector with priority 0 for https://nexus.codehaus.org/service/local/staging/deploy/maven2/ as stephenconnolly Uploading: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom Nov 29, 2011 10:06:08 AM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme INFO: basic authentication scheme selected [DEBUG] Failed to upload SHA-1 checksum for /Users/stephenc/codehaus/mrm/target/checkout/pom.xml: Should not be using the streaming wagon for HTTP PUT java.lang.IllegalStateException: Should not be using the streaming wagon for HTTP PUT at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillOutputData(AbstractHttpClientWagon.java:692) at org.apache.maven.wagon.StreamWagon.getOutputStream(StreamWagon.java:188) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:272) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:252) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksum(WagonRepositoryConnector.java:885) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksums(WagonRepositoryConnector.java:861) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:818) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:467) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:274) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:211) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:443) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:137) at org.apache.maven.plugin.deploy.AbstractDeployMojo.deploy(AbstractDeployMojo.java:167) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:149) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute
Re: [VOTE] Apache Maven 3.0.4
Out of curiosity, why is chunked transfer encoding used to transfer the few byte long SHA1 string? Personally, I'd avoid the use of chunked whenever possible, since -- just like this example shows -- many servers does not support it completely... Thanks, ~t~ On Tue, Nov 29, 2011 at 1:21 PM, Olivier Lamy ol...@apache.org wrote: Thanks. That's what I have seen. Content-Lenght is null because chunked is used. I will enhance core it to ensure Content-Length header is correct and update wagon http to fix that. BTW canceling a release because a http server does not support chunck is a pain 2011/11/29 Tamás Cservenák ta...@cservenak.net: Hi, Nexus does not respond with HTTP 411. It has to be some nexus-fronting app (httpd or nginx?) And I am 99% confident that according to RFC[1], this was a case of incomplete request or such. As I inspected, nexus@codehaus is fronted by nginx 0.8.24 By googling, I found this: http://www.lamnk.com/blog/computer/fix-nginx-411-length-required-error/ [1] http://tools.ietf.org/html/rfc2616 Thanks, ~t~ On Tue, Nov 29, 2011 at 12:35 PM, Olivier Lamy ol...@apache.org wrote: Agree I will cancel the vote to investigate more. I wonder why it works when deploying maven scm to repository.apache.org and tested on a locally installed nexus instance ? Can nexus folks who are listening here explains to me in which case this happen http Return code: 411, ReasonPhrase:Length Required. Bad or empty Content-Length http header ? 2011/11/29 Mark Struberg strub...@yahoo.de: I think delivering artifacts without md5 and sha1 is pretty much a blocker as this might introduce security issues along the line. So I'd say we investigate further before we go ahead. Thus I change my vote to a -1 (binding) also. We now have a few cases which work well and a few cases which cause this error. Means we have to check where the difference is. LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org Cc: Sent: Tuesday, November 29, 2011 11:14 AM Subject: Re: [VOTE] Apache Maven 3.0.4 I see the same checksum issue when trying to deploy a snapshot over at Codehaus mojo: https://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/mojo/jboss-packaging-maven-plugin/2.3-SNAPSHOT/ I'm changing my vote to -1 (non-binding). IMHO we do not want end user issues due to something like this. /Anders On Tue, Nov 29, 2011 at 11:09, Stephen Connolly stephen.alan.conno...@gmail.com wrote: That stacktrace was with extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version2.1/version /extension /extensions in the pom... if I try extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version1.0/version /extension /extensions I get [DEBUG] Using connector WagonRepositoryConnector with priority 0 for https://nexus.codehaus.org/service/local/staging/deploy/maven2/ as stephenconnolly Uploading: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom Nov 29, 2011 10:06:08 AM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme INFO: basic authentication scheme selected [DEBUG] Failed to upload SHA-1 checksum for /Users/stephenc/codehaus/mrm/target/checkout/pom.xml: Should not be using the streaming wagon for HTTP PUT java.lang.IllegalStateException: Should not be using the streaming wagon for HTTP PUT at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillOutputData(AbstractHttpClientWagon.java:692) at org.apache.maven.wagon.StreamWagon.getOutputStream(StreamWagon.java:188) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:272) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:252) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksum(WagonRepositoryConnector.java:885) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksums(WagonRepositoryConnector.java:861) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:818) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:467) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:274) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:211) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:443) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:137) at org.apache.maven.plugin.deploy.AbstractDeployMojo.deploy
Re: [VOTE] Apache Maven 3.0.4
because for those files the streaming api is used. something like putFromStream( InputStream stream, String destination ) so to know the size I will have to dump the stream to a tmp file to calculate the size. (crazy) 2011/11/29 Tamás Cservenák ta...@cservenak.net: Out of curiosity, why is chunked transfer encoding used to transfer the few byte long SHA1 string? Personally, I'd avoid the use of chunked whenever possible, since -- just like this example shows -- many servers does not support it completely... Thanks, ~t~ On Tue, Nov 29, 2011 at 1:21 PM, Olivier Lamy ol...@apache.org wrote: Thanks. That's what I have seen. Content-Lenght is null because chunked is used. I will enhance core it to ensure Content-Length header is correct and update wagon http to fix that. BTW canceling a release because a http server does not support chunck is a pain 2011/11/29 Tamás Cservenák ta...@cservenak.net: Hi, Nexus does not respond with HTTP 411. It has to be some nexus-fronting app (httpd or nginx?) And I am 99% confident that according to RFC[1], this was a case of incomplete request or such. As I inspected, nexus@codehaus is fronted by nginx 0.8.24 By googling, I found this: http://www.lamnk.com/blog/computer/fix-nginx-411-length-required-error/ [1] http://tools.ietf.org/html/rfc2616 Thanks, ~t~ On Tue, Nov 29, 2011 at 12:35 PM, Olivier Lamy ol...@apache.org wrote: Agree I will cancel the vote to investigate more. I wonder why it works when deploying maven scm to repository.apache.org and tested on a locally installed nexus instance ? Can nexus folks who are listening here explains to me in which case this happen http Return code: 411, ReasonPhrase:Length Required. Bad or empty Content-Length http header ? 2011/11/29 Mark Struberg strub...@yahoo.de: I think delivering artifacts without md5 and sha1 is pretty much a blocker as this might introduce security issues along the line. So I'd say we investigate further before we go ahead. Thus I change my vote to a -1 (binding) also. We now have a few cases which work well and a few cases which cause this error. Means we have to check where the difference is. LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org Cc: Sent: Tuesday, November 29, 2011 11:14 AM Subject: Re: [VOTE] Apache Maven 3.0.4 I see the same checksum issue when trying to deploy a snapshot over at Codehaus mojo: https://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/mojo/jboss-packaging-maven-plugin/2.3-SNAPSHOT/ I'm changing my vote to -1 (non-binding). IMHO we do not want end user issues due to something like this. /Anders On Tue, Nov 29, 2011 at 11:09, Stephen Connolly stephen.alan.conno...@gmail.com wrote: That stacktrace was with extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version2.1/version /extension /extensions in the pom... if I try extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version1.0/version /extension /extensions I get [DEBUG] Using connector WagonRepositoryConnector with priority 0 for https://nexus.codehaus.org/service/local/staging/deploy/maven2/ as stephenconnolly Uploading: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom Nov 29, 2011 10:06:08 AM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme INFO: basic authentication scheme selected [DEBUG] Failed to upload SHA-1 checksum for /Users/stephenc/codehaus/mrm/target/checkout/pom.xml: Should not be using the streaming wagon for HTTP PUT java.lang.IllegalStateException: Should not be using the streaming wagon for HTTP PUT at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillOutputData(AbstractHttpClientWagon.java:692) at org.apache.maven.wagon.StreamWagon.getOutputStream(StreamWagon.java:188) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:272) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:252) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksum(WagonRepositoryConnector.java:885) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksums(WagonRepositoryConnector.java:861) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:818) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:467) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:274) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:211
Re: [VOTE] Apache Maven 3.0.4
btw for who interested benjamin (thanks !) did a quick change on aether to have content length passed to wagon which fix the issue (a core it test has been changed to failed in case chunked is used) I'm waiting now the release 1.14 available in central to start again the release process. 2011/11/29 Olivier Lamy ol...@apache.org: because for those files the streaming api is used. something like putFromStream( InputStream stream, String destination ) so to know the size I will have to dump the stream to a tmp file to calculate the size. (crazy) 2011/11/29 Tamás Cservenák ta...@cservenak.net: Out of curiosity, why is chunked transfer encoding used to transfer the few byte long SHA1 string? Personally, I'd avoid the use of chunked whenever possible, since -- just like this example shows -- many servers does not support it completely... Thanks, ~t~ On Tue, Nov 29, 2011 at 1:21 PM, Olivier Lamy ol...@apache.org wrote: Thanks. That's what I have seen. Content-Lenght is null because chunked is used. I will enhance core it to ensure Content-Length header is correct and update wagon http to fix that. BTW canceling a release because a http server does not support chunck is a pain 2011/11/29 Tamás Cservenák ta...@cservenak.net: Hi, Nexus does not respond with HTTP 411. It has to be some nexus-fronting app (httpd or nginx?) And I am 99% confident that according to RFC[1], this was a case of incomplete request or such. As I inspected, nexus@codehaus is fronted by nginx 0.8.24 By googling, I found this: http://www.lamnk.com/blog/computer/fix-nginx-411-length-required-error/ [1] http://tools.ietf.org/html/rfc2616 Thanks, ~t~ On Tue, Nov 29, 2011 at 12:35 PM, Olivier Lamy ol...@apache.org wrote: Agree I will cancel the vote to investigate more. I wonder why it works when deploying maven scm to repository.apache.org and tested on a locally installed nexus instance ? Can nexus folks who are listening here explains to me in which case this happen http Return code: 411, ReasonPhrase:Length Required. Bad or empty Content-Length http header ? 2011/11/29 Mark Struberg strub...@yahoo.de: I think delivering artifacts without md5 and sha1 is pretty much a blocker as this might introduce security issues along the line. So I'd say we investigate further before we go ahead. Thus I change my vote to a -1 (binding) also. We now have a few cases which work well and a few cases which cause this error. Means we have to check where the difference is. LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org Cc: Sent: Tuesday, November 29, 2011 11:14 AM Subject: Re: [VOTE] Apache Maven 3.0.4 I see the same checksum issue when trying to deploy a snapshot over at Codehaus mojo: https://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/mojo/jboss-packaging-maven-plugin/2.3-SNAPSHOT/ I'm changing my vote to -1 (non-binding). IMHO we do not want end user issues due to something like this. /Anders On Tue, Nov 29, 2011 at 11:09, Stephen Connolly stephen.alan.conno...@gmail.com wrote: That stacktrace was with extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version2.1/version /extension /extensions in the pom... if I try extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version1.0/version /extension /extensions I get [DEBUG] Using connector WagonRepositoryConnector with priority 0 for https://nexus.codehaus.org/service/local/staging/deploy/maven2/ as stephenconnolly Uploading: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom Nov 29, 2011 10:06:08 AM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme INFO: basic authentication scheme selected [DEBUG] Failed to upload SHA-1 checksum for /Users/stephenc/codehaus/mrm/target/checkout/pom.xml: Should not be using the streaming wagon for HTTP PUT java.lang.IllegalStateException: Should not be using the streaming wagon for HTTP PUT at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillOutputData(AbstractHttpClientWagon.java:692) at org.apache.maven.wagon.StreamWagon.getOutputStream(StreamWagon.java:188) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:272) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:252) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksum(WagonRepositoryConnector.java:885) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksums(WagonRepositoryConnector.java:861) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run
Re: [VOTE] Apache Maven 3.0.4
CXF has a nice CachedOutputStream that fits into this space. Let me know of I can help. On Tue, Nov 29, 2011 at 6:35 AM, Olivier Lamy ol...@apache.org wrote: Agree I will cancel the vote to investigate more. I wonder why it works when deploying maven scm to repository.apache.org and tested on a locally installed nexus instance ? Can nexus folks who are listening here explains to me in which case this happen http Return code: 411, ReasonPhrase:Length Required. Bad or empty Content-Length http header ? 2011/11/29 Mark Struberg strub...@yahoo.de: I think delivering artifacts without md5 and sha1 is pretty much a blocker as this might introduce security issues along the line. So I'd say we investigate further before we go ahead. Thus I change my vote to a -1 (binding) also. We now have a few cases which work well and a few cases which cause this error. Means we have to check where the difference is. LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org Cc: Sent: Tuesday, November 29, 2011 11:14 AM Subject: Re: [VOTE] Apache Maven 3.0.4 I see the same checksum issue when trying to deploy a snapshot over at Codehaus mojo: https://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/mojo/jboss-packaging-maven-plugin/2.3-SNAPSHOT/ I'm changing my vote to -1 (non-binding). IMHO we do not want end user issues due to something like this. /Anders On Tue, Nov 29, 2011 at 11:09, Stephen Connolly stephen.alan.conno...@gmail.com wrote: That stacktrace was with extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version2.1/version /extension /extensions in the pom... if I try extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version1.0/version /extension /extensions I get [DEBUG] Using connector WagonRepositoryConnector with priority 0 for https://nexus.codehaus.org/service/local/staging/deploy/maven2/ as stephenconnolly Uploading: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom Nov 29, 2011 10:06:08 AM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme INFO: basic authentication scheme selected [DEBUG] Failed to upload SHA-1 checksum for /Users/stephenc/codehaus/mrm/target/checkout/pom.xml: Should not be using the streaming wagon for HTTP PUT java.lang.IllegalStateException: Should not be using the streaming wagon for HTTP PUT at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillOutputData(AbstractHttpClientWagon.java:692) at org.apache.maven.wagon.StreamWagon.getOutputStream(StreamWagon.java:188) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:272) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:252) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksum(WagonRepositoryConnector.java:885) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksums(WagonRepositoryConnector.java:861) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:818) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:467) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:274) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:211) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:443) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:137) at org.apache.maven.plugin.deploy.AbstractDeployMojo.deploy(AbstractDeployMojo.java:167) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:149) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute
Re: [VOTE] Apache Maven 3.0.4
1.13.1 AFAIR on irc :-) On Tue, Nov 29, 2011 at 2:17 PM, Olivier Lamy ol...@apache.org wrote: btw for who interested benjamin (thanks !) did a quick change on aether to have content length passed to wagon which fix the issue (a core it test has been changed to failed in case chunked is used) I'm waiting now the release 1.14 available in central to start again the release process. 2011/11/29 Olivier Lamy ol...@apache.org: because for those files the streaming api is used. something like putFromStream( InputStream stream, String destination ) so to know the size I will have to dump the stream to a tmp file to calculate the size. (crazy) 2011/11/29 Tamás Cservenák ta...@cservenak.net: Out of curiosity, why is chunked transfer encoding used to transfer the few byte long SHA1 string? Personally, I'd avoid the use of chunked whenever possible, since -- just like this example shows -- many servers does not support it completely... Thanks, ~t~ On Tue, Nov 29, 2011 at 1:21 PM, Olivier Lamy ol...@apache.org wrote: Thanks. That's what I have seen. Content-Lenght is null because chunked is used. I will enhance core it to ensure Content-Length header is correct and update wagon http to fix that. BTW canceling a release because a http server does not support chunck is a pain 2011/11/29 Tamás Cservenák ta...@cservenak.net: Hi, Nexus does not respond with HTTP 411. It has to be some nexus-fronting app (httpd or nginx?) And I am 99% confident that according to RFC[1], this was a case of incomplete request or such. As I inspected, nexus@codehaus is fronted by nginx 0.8.24 By googling, I found this: http://www.lamnk.com/blog/computer/fix-nginx-411-length-required-error/ [1] http://tools.ietf.org/html/rfc2616 Thanks, ~t~ On Tue, Nov 29, 2011 at 12:35 PM, Olivier Lamy ol...@apache.org wrote: Agree I will cancel the vote to investigate more. I wonder why it works when deploying maven scm to repository.apache.org and tested on a locally installed nexus instance ? Can nexus folks who are listening here explains to me in which case this happen http Return code: 411, ReasonPhrase:Length Required. Bad or empty Content-Length http header ? 2011/11/29 Mark Struberg strub...@yahoo.de: I think delivering artifacts without md5 and sha1 is pretty much a blocker as this might introduce security issues along the line. So I'd say we investigate further before we go ahead. Thus I change my vote to a -1 (binding) also. We now have a few cases which work well and a few cases which cause this error. Means we have to check where the difference is. LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org Cc: Sent: Tuesday, November 29, 2011 11:14 AM Subject: Re: [VOTE] Apache Maven 3.0.4 I see the same checksum issue when trying to deploy a snapshot over at Codehaus mojo: https://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/mojo/jboss-packaging-maven-plugin/2.3-SNAPSHOT/ I'm changing my vote to -1 (non-binding). IMHO we do not want end user issues due to something like this. /Anders On Tue, Nov 29, 2011 at 11:09, Stephen Connolly stephen.alan.conno...@gmail.com wrote: That stacktrace was with extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version2.1/version /extension /extensions in the pom... if I try extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version1.0/version /extension /extensions I get [DEBUG] Using connector WagonRepositoryConnector with priority 0 for https://nexus.codehaus.org/service/local/staging/deploy/maven2/as stephenconnolly Uploading: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom Nov 29, 2011 10:06:08 AM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme INFO: basic authentication scheme selected [DEBUG] Failed to upload SHA-1 checksum for /Users/stephenc/codehaus/mrm/target/checkout/pom.xml: Should not be using the streaming wagon for HTTP PUT java.lang.IllegalStateException: Should not be using the streaming wagon for HTTP PUT at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillOutputData(AbstractHttpClientWagon.java:692) at org.apache.maven.wagon.StreamWagon.getOutputStream(StreamWagon.java:188) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:272) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:252) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksum
Re: [VOTE] Apache Maven 3.0.4
Tamás Cservenák wrote: Out of curiosity, why is chunked transfer encoding used to transfer the few byte long SHA1 string? https://issues.sonatype.org/browse/AETHER-128 many servers does not support it completely... Which suggests to deprecate the problematic method in the StreamingWagon API. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
deprecate a method for wagon stream api (was Re: [VOTE] Apache Maven 3.0.4 )
2011/11/29 Benjamin Bentmann benjamin.bentm...@udo.edu: Tamás Cservenák wrote: Out of curiosity, why is chunked transfer encoding used to transfer the few byte long SHA1 string? https://issues.sonatype.org/browse/AETHER-128 many servers does not support it completely... Which suggests to deprecate the problematic method in the StreamingWagon API. Agree I will . Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [CANCEL VOTE] Apache Maven 3.0.4
I think doing RCs like we have done in the past for all other 3.x releases might be a good idea. On Nov 29, 2011, at 4:00 AM, Olivier Lamy wrote: So due to issues when releasing project and missing md5/sha1 on some env whereas not on other. The vote is cancelled for more investigations. 2011/11/25 Olivier Lamy ol...@apache.org: Hello, I'd like to release Apache Maven 3.0.4. We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 The staged repo is available here: https://repository.apache.org/content/repositories/maven-244/ . The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote (which is around 120 hours) [+1] [0] [-1] Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks
Re: deprecate a method for wagon stream api (was Re: [VOTE] Apache Maven 3.0.4 )
Note that it wasn't really called until r1179571, so I think maybe the
http-shared module should go back to not supporting it. I suppose that was
added for Aether, which in turn is no longer needed :)
While looking at that I noticed this code is probably being called for anything
using the new putFromStream:
FileOutputStream fos = null;
try
{
this.source = File.createTempFile( http-wagon., .tmp );
this.source.deleteOnExit();
fos = new FileOutputStream( this.source );
IOUtil.copy( stream, fos );
John authored this code a long time ago:
http://svn.apache.org/viewvc?view=revisionrevision=786701. I get the feeling
with your recent changes this hack might no longer be necessary.
Finally, why do we still have both http-shared and http-shared4?
- Brett
On 30/11/2011, at 12:59 AM, Olivier Lamy wrote:
2011/11/29 Benjamin Bentmann benjamin.bentm...@udo.edu:
Tamás Cservenák wrote:
Out of curiosity, why is chunked transfer encoding used to transfer
the few byte long SHA1 string?
https://issues.sonatype.org/browse/AETHER-128
many servers does not support it
completely...
Which suggests to deprecate the problematic method in the StreamingWagon
API.
Agree I will .
Benjamin
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
+1 (non-binding) /Anders On Mon, Nov 28, 2011 at 09:01, Emmanuel Venisse emmanuel.veni...@gmail.com wrote: +1 (binding) Emmanuel On Fri, Nov 25, 2011 at 10:17 AM, Olivier Lamy ol...@apache.org wrote: Hello, I'd like to release Apache Maven 3.0.4. We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 The staged repo is available here: https://repository.apache.org/content/repositories/maven-244/ . The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote (which is around 120 hours) [+1] [0] [-1] Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
Excerpts from Arnaud Héritier's message of Sat Nov 26 00:37:09 +0100 2011: ... it might be really useful to add a link to release notes of components we upgraded like wagon, sisu or aether. I'm not sure that for all issues solved in these projects we have an MNG issue ? And nowadays we could have important maven issues hidden in such sub-components. It is just a proposal to try to give to users a better overview of changes This would be really great not just for users, but also for packagers in Linux distributions (i.e. me). I'll find out about updated deps one way or the other, but it would be nice to have it stated in the release notes if possible. So: pretty please do this :-) -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: PGP signature
Re: [VOTE] Apache Maven 3.0.4
+1 No problems found on any of the projects I have tried it on. I've been using it all day long @dayjob. On 2011-11-25 10:17, Olivier Lamy wrote: Hello, I'd like to release Apache Maven 3.0.4. We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 The staged repo is available here: https://repository.apache.org/content/repositories/maven-244/ . The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote (which is around 120 hours) [+1] [0] [-1] Here my +1 Thanks, -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
+1 (non-binding) -- Cheers, Stuart On 25 Nov 2011, at 09:17, Olivier Lamy wrote: Hello, I'd like to release Apache Maven 3.0.4. We fixed 31 issues. See release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17215 The staged repo is available here: https://repository.apache.org/content/repositories/maven-244/ . The staged distributions are available here: http://people.apache.org/builds/maven/3.0.4/ As we are near the week end, the vote will be a 5 days vote (which is around 120 hours) [+1] [0] [-1] Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
+1 (non-binding). Tested integration into a NetBeans development build, and built some modules in Glassfish, so far without problem. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
