Re: PROPOSAL: Remote Profiles ( a limited alternative to mixins )
On Sat, Dec 3, 2011 at 5:50 AM, Mark Derricutt m...@talios.com wrote: Hey all, I was thinking again the other day about how mixins could be introduced to maven to improve/fix some of the issues found with the rigid parent/child lineage of poms. Maintaining common meta-data without mixin's is a major PITA for projects like James who have scores of modules organised by consumer product not function. It leads to lots of unnecessary duplication. Robert - 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
Re: PROPOSAL: Remote Profiles ( a limited alternative to mixins )
The profile mechanism is how any new mixin system would work. No other mechanism internally is really suited to provide full access to the model in the right place. Not sure if you looked at the code or this is intuition on your part but your analysis is correct in that it's collaboration with the profile mechanism. This is how mixins should work. If you want to try you can take my bastardization and see if you can get it to work. But I would still encourage you to analyze what it would mean to grab something remotely, mix it in, and the resultant stability of the system. On Dec 2, 2011, at 9:50 PM, Mark Derricutt wrote: Hey all, I was thinking again the other day about how mixins could be introduced to maven to improve/fix some of the issues found with the rigid parent/child lineage of poms. At the same time I was looking at the remote-resources plugin and a small lightbulb went on in my mind - we all ready have profiles in maven, for packaging up settings - why can't we source those profiles from a repository? Something like: ?xml version=1.0 encoding=UTF-8? 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 ... profiles profile idosgibundle/id dependency groupIdcom.talios/groupId artifactIdosgibundle/artifactId version1.0.3/version /dependency /profile /profiles /project In this project, we have a profile defined with an ID, and a single top-level dependency which would direct maven to download the POM identified by the dependency, and look for a profile defined with the same ID - and inline it's definition and continue as normal. The caveats around this would be something like: - if your profile has a dependency element, then it MUST ONLY contain id and dependency - The dependency type is assumed to be typepom/type. - Similar to plugins, version ranges SHOULD NOT be resolvable ( looking at [1] this allows maven to have a more guaranteed project outcome, just as tho the profile was defined in the POM directly ). Unlike a totally new mixin system, this is an evolution of an existing maven context, which may make it easier for people to understand. Thoughts? [1] http://maven.apache.org/guides/introduction/introduction-to-profiles.html -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language
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] Release Maven Surefire version 2.11, take 2
+1 Hervé Le Mercredi 30 Novembre 2011 15:07:03 Kristian Rosenvold a écrit : Hi, We solved 22 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=178 56 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 Changes to the proposed Surefire API are documented in the API section of the site, which also has a lovely new skin, thanks to Simon! This version is marked as the last java 1.4 compatible version in JIRA, the next version will be java 1.5 for the plugin. Surefire can still *fork* all the way down to jdk 1.3 for JUnit 3.8.1. There are still lots of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejql Query=project+%3D+ SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Staging repo: https://repository.apache.org/content/repositories/maven-272/ Staging site (sync pending): http://maven.apache.org/surefire-2.11/ http://maven.apache.org/plugins/maven-failsafe-plugin-2.11/ http://maven.apache.org/plugins/maven-surefire-plugin-2.11/ http://maven.apache.org/plugins/maven-surefire-reports-plugin-2.11/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 And here's my +1 Kristian - 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 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
