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
[RESULT] [VOTE] Release Maven Surefire version 2.11, take 2
Hi, The vote has passed with the following result : +1 (binding): Lamy, Boutemy, Rosenvold I will promote the artifacts to the central repo.
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
[ANN] Maven Surefire Plugin 2.11 Released
The Maven team is pleased to announce the release of the Maven Surefire Plugin, version 2.11 This release includes the maven-surefire-plugin, which executes the unit tests of an application, the maven-surefire-report-plugin, which parses surefire/failsafe test results and renders them to DOXIA creating the web interface version of the test results, as well as the maven-failsafe-plugin, which executes the integration tests of an application. This version supports JUnit 4.8 @Category annotation, using the groups parameter on the plugin (using the 4.7 provider). The other new feature in this release are runOrder=failedfirst and runOrder=balanced, this last parameter tries to optimize the overall run-time for parallel test runs. Users migrating from classic JUnit4 to the 4.7 provider to use categories may want to take note of http://jira.codehaus.org/browse/SUREFIRE-798 Users having troubles running with forkMode=never for 2.9 and 2.10 may want to take note of http://jira.codehaus.org/browse/SUREFIRE-http://jira.codehaus.org/browse/SUREFIRE-798 801. Changes to the proposed Surefire API are documented in the API page http://maven.apache.org/plugins/maven-surefire-plugin/api.html This version is marked as the last java 1.4 compatible version, the next version will be java 1.5. Surefire can still *fork* all the way down to jdk 1.3 for JUnit 3.8.1. http://maven.apache.org/plugins/maven-surefire-plugin/ http://maven.apache.org/plugins/maven-failsafe-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.11/version /plugin Release Notes - Maven Surefire - Version 2.11 ** Bug * [SUREFIRE-508] - cannot run GWTTestCases with surefire * [SUREFIRE-549] - TestNg provider does not run junit tests correctly when forkMode=always * [SUREFIRE-746] - Other registered failing RunListeners cause NullPointerException in ConcurrentReporterManager, falsely report of No tests were executed!: * [SUREFIRE-760] - mvn -Dtest=ClassName#methodName does not work with parallel tests * [SUREFIRE-775] - ForkingRunListener throws ArrayIndexOutOfBoundsException * [SUREFIRE-777] - Wrong default name for Failsafe Report * [SUREFIRE-780] - Success claimed when jvm fails to launch * [SUREFIRE-782] - Wrong links on surefire-plugin page * [SUREFIRE-785] - Lots of newlines being strewn about in test output * [SUREFIRE-786] - JUnit @Category are not taken into account if forkMode=always * [SUREFIRE-787] - Test fail cause message is badly displayed if exception message conatins line feeds * [SUREFIRE-791] - JUnit47 provider reports incorrect elapsed time on test failure. * [SUREFIRE-793] - JUnit47 provider reports incorrect time in the XML report * [SUREFIRE-801] - Classloading compatibility break with forkMode=NEVER in 2.9 and 2.10 ** Improvement * [SUREFIRE-518] - Do not generate empty ouput files when redirectTestOutputToFile is enabled * [SUREFIRE-611] - surefire exit code should explicitly distinguish between crashed and failed unit test(s) * [SUREFIRE-772] - [Report Goal] Skip Maven Failsafe Report ** New Feature * [SUREFIRE-656] - JUnit 4.8 @Category support * [SUREFIRE-795] - There should be a way to balance tests across threads ** Story * [SUREFIRE-784] - Surefire plugin cannot be debugged remotely by eclipse ** Task * [SUREFIRE-802] - Dcoument Surefire API changes ** Wish * [SUREFIRE-329] - Support for JUNIT extensions Enjoy, -The Maven team
[ANN] Maven Surefire Plugin 2.11 Released
The Maven team is pleased to announce the release of the Maven Surefire Plugin, version 2.11 This release includes the maven-surefire-plugin, which executes the unit tests of an application, the maven-surefire-report-plugin, which parses surefire/failsafe test results and renders them to DOXIA creating the web interface version of the test results, as well as the maven-failsafe-plugin, which executes the integration tests of an application. This version supports JUnit 4.8 @Category annotation, using the groups parameter on the plugin (using the 4.7 provider). The other new feature in this release are runOrder=failedfirst and runOrder=balanced, this last parameter tries to optimize the overall run-time for parallel test runs. Users migrating from classic JUnit4 to the 4.7 provider to use categories may want to take note of http://jira.codehaus.org/browse/SUREFIRE-798 Users having troubles running with forkMode=never for 2.9 and 2.10 may want to take note of http://jira.codehaus.org/browse/SUREFIRE-801. Changes to the proposed Surefire API are documented in the API page http://maven.apache.org/plugins/maven-surefire-plugin/api.html This version is marked as the last java 1.4 compatible version, the next version will be java 1.5. Surefire can still fork all the way down to jdk 1.3 for JUnit 3.8.1. http://maven.apache.org/plugins/maven-surefire-plugin/ http://maven.apache.org/plugins/maven-failsafe-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.11/version /plugin Release Notes - Maven Surefire - Version 2.11 ** Bug * [SUREFIRE-508] - cannot run GWTTestCases with surefire * [SUREFIRE-549] - TestNg provider does not run junit tests correctly when forkMode=always * [SUREFIRE-746] - Other registered failing RunListeners cause NullPointerException in ConcurrentReporterManager, falsely report of No tests were executed!: * [SUREFIRE-760] - mvn -Dtest=ClassName#methodName does not work with parallel tests * [SUREFIRE-775] - ForkingRunListener throws ArrayIndexOutOfBoundsException * [SUREFIRE-777] - Wrong default name for Failsafe Report * [SUREFIRE-780] - Success claimed when jvm fails to launch * [SUREFIRE-782] - Wrong links on surefire-plugin page * [SUREFIRE-785] - Lots of newlines being strewn about in test output * [SUREFIRE-786] - JUnit @Category are not taken into account if forkMode=always * [SUREFIRE-787] - Test fail cause message is badly displayed if exception message conatins line feeds * [SUREFIRE-791] - JUnit47 provider reports incorrect elapsed time on test failure. * [SUREFIRE-793] - JUnit47 provider reports incorrect time in the XML report * [SUREFIRE-801] - Classloading compatibility break with forkMode=NEVER in 2.9 and 2.10 ** Improvement * [SUREFIRE-518] - Do not generate empty ouput files when redirectTestOutputToFile is enabled * [SUREFIRE-611] - surefire exit code should explicitly distinguish between crashed and failed unit test(s) * [SUREFIRE-772] - [Report Goal] Skip Maven Failsafe Report ** New Feature * [SUREFIRE-656] - JUnit 4.8 @Category support * [SUREFIRE-795] - There should be a way to balance tests across threads ** Story * [SUREFIRE-784] - Surefire plugin cannot be debugged remotely by eclipse ** Task * [SUREFIRE-802] - Dcoument Surefire API changes ** Wish * [SUREFIRE-329] - Support for JUNIT extensions Enjoy, -The Maven team - 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
