Re: maven-core tests fail when invoked via ant.
I somehow think that if I was to do this integration I'd consider reversing the order; build maven3 from scratch and then use maven3 to build the older versions. Kristian Den 20.06.2011 07:52, skrev Kasun Gajasinghe: Hi Brett, On Mon, Jun 20, 2011 at 5:41 AM, Brett Porterbr...@apache.org wrote: The problem you're seeing is probably related to an incorrect definition of a META-INF/plexus/components.xml file related to that SecDispatcher component. You're probably pulling in a file you didn't intend to. Hopefully you can grep through the test resources and find the culprit. Yes, thanks. maven-core uses plexus-sec-dispatcher version 1.3, which doesn't contain arole-hint in META-INF/plexus/components.xml. So, I've updated the version to 1.4, and the test error I mentioned is gone. Well, now there's a test _failure_ (not error), in MavenCliTest, which I've identified as due to the wrong compilation version. i.e. according to maven-core pom, **/cli/*.java files should be compiled using JDK 1.4 while the rest of classes using 1.5. But apparently, the generated build.xml disregard this setting and compiles the whole bunch using 1.5. Is this a bug in the maven ant plugin or ant is incapable of handling this kind of thing? Is there a reason you can't use the build.xml we've already provided for those that need to bootstrap? Hopefully that would simplify things for you. Since we have to package the sub-modules separately, we can't use the provided build.xml. Building via mvn ant:ant too isn't a much of a problem. But these test failures is a concern. Thanks for the help! --Kasun - Brett On 19/06/2011, at 4:34 PM, Kasun Gajasinghe wrote: Hi, We are in the process of integrating Maven in to Gentoo. Currently, we are trying to bootstrap maven. Our strategy is to integrate each and every sub-project of Maven-2.2.1 [1] separately. So, we first transformed these to an ant projects by generating the build.xml via `mvn ant:ant`. I know that Maven provides a build.xml in the parent, but we have to integrate each and every project separately. We will be moving to 3.x after 2.x is complete. We chose 2.x as it's much stable, and is much popular currently. So far, we have successfully integrated project up-to maven-core in the build order. But, we are encountering an issue in maven-core. When invoked via mvn (mvn install), it passes the tests successfully (obviously!). But when I invoke the project via ant, a test fails with an ERROR. I'm sending this to the dev group thinking this error is probably obvious to you all. = test: [mkdir] Created dir: /gentoo-sources/maven/maven-2/tags/maven-2.2.1/maven-core-2.2.1/target/test-reports [junit] Running org.apache.maven.WagonSelectorTest [junit] Testsuite: org.apache.maven.WagonSelectorTest [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.361 sec [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.361 sec [junit] [junit] Testcase: testSelectHttpWagonFromDefault took 0.358 sec [junit] Caused an ERROR [junit] Error starting container [junit] org.codehaus.plexus.PlexusContainerException: Error starting container [junit] at org.codehaus.plexus.DefaultPlexusContainer.start(DefaultPlexusContainer.java:795) [junit] at org.codehaus.plexus.PlexusTestCase.setUp(PlexusTestCase.java:121) [junit] at org.apache.maven.WagonSelectorTest.setUp(WagonSelectorTest.java:76) [junit] Caused by: org.codehaus.plexus.component.repository.exception.ComponentRepositoryException: Component descriptor role: 'org.sonatype.plexus.components.sec.dispatcher.SecDispatcher', implementation: 'org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher', role hint: 'maven' has a hint, but there are other implementations that don't [junit] at org.codehaus.plexus.component.repository.DefaultComponentRepository.addComponentDescriptor(DefaultComponentRepository.java:184) [junit] at org.codehaus.plexus.DefaultPlexusContainer.addComponentDescriptor(DefaultPlexusContainer.java:515) [junit] at org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:738) [junit] at org.codehaus.plexus.DefaultPlexusContainer.start(DefaultPlexusContainer.java:779) [junit] BUILD FAILED /gentoo-sources/maven/maven-2/tags/maven-2.2.1/maven-core-2.2.1/maven-build.xml:206: Test org.apache.maven.WagonSelectorTest failed = Any clues on getting rid of this error? I'm thinking whether the generated build.xml has some issue. Much appreciate your help! The maven-build.xml is at [2]. The full ant output of the test failure is at [3]. I'm using maven-ant-plugin-2.3 with maven-2.2.1. The test fails with both ant 1.7.1 and 1.8.1. Please do let me know if any other information is needed. [1]
Re: [VOTE]: release maven-changes-plugin 2.6
Den 19.06.2011 23:08, skrev Gavin McDonald: I would be happy with weeks to be honest. Then again I have been used to being around slower projects that have released only every 2 or 3 years once 1 or 2 hundred issues have been gathered into a release. And the release process itself takes weeks of work to achieve. Therefore ignore me, 3 issues seems like doing a days work, then release, then another days work, then release etc ... Given a very quick count, the apache maven project contains something like 90 individually deployable and separately votable artifacts. Our users upgrade these components individually according to need. Each component is individually tested and voted for; maven is not a monolithic application and should not be released as one. The downside of this componentization is that sometimes fixing a single issue leads to the redeployment of multiple artifacts, at the moment I'm working on 1 issue that will require the redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere) before it's closed in its full extent. Most likely I'll have votes for 2 of these soon and I'll just let the remaining 4 roll out together with releases planned by others. But in this context I simply refuse to consider if a single release vote is too large or too small. From an agile perspective there's potential to getting a lot more issues fixed with a single year than the kind of project you mention. I have no specific stats but I assume we fix at least a thousand issues every year. Some of our projects have sufficiently good automated test coverage that I suspect we could allow incremental .1 releases to go without a vote entirely. I'm not sure if this is something we're even allowed to consider ;) (Surefire would probably qualify, assuming we did some kind of formalized continious production kind of review) I think ideally we should release every top-level component every 6 weeks or so. But that means we'd have 1-3 votes every day ;) Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven-core tests fail when invoked via ant.
On Mon, Jun 20, 2011 at 11:41 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I somehow think that if I was to do this integration I'd consider reversing the order; build maven3 from scratch and then use maven3 to build the older versions. Kristian, Thanks for the suggestion. But we've come this far, now only few packages left. So, I think it's better to go ahead with current implementation and then add maven3, isn't it? And, regarding the compiling **/cli/**java with 1.4, I actually don't see that when compiling via maven either. I'm probably wrong here, but I see that during the execution default everything compiles. When it comes to cli execution phase, what I see is [INFO] Nothing to compile - all classes are up to date. (Yes, I did a mvn clean first!) The debug log is at http://pastebin.com/EK01GFRf This is just what I noticed, and there's high chance that I didn't correctly understand the debug logs. :-) Thanks, --Kasun Kristian Den 20.06.2011 07:52, skrev Kasun Gajasinghe: Hi Brett, On Mon, Jun 20, 2011 at 5:41 AM, Brett Porterbr...@apache.org wrote: The problem you're seeing is probably related to an incorrect definition of a META-INF/plexus/components.xml file related to that SecDispatcher component. You're probably pulling in a file you didn't intend to. Hopefully you can grep through the test resources and find the culprit. Yes, thanks. maven-core uses plexus-sec-dispatcher version 1.3, which doesn't contain arole-hint in META-INF/plexus/components.**xml. So, I've updated the version to 1.4, and the test error I mentioned is gone. Well, now there's a test _failure_ (not error), in MavenCliTest, which I've identified as due to the wrong compilation version. i.e. according to maven-core pom, **/cli/*.java files should be compiled using JDK 1.4 while the rest of classes using 1.5. But apparently, the generated build.xml disregard this setting and compiles the whole bunch using 1.5. Is this a bug in the maven ant plugin or ant is incapable of handling this kind of thing? Is there a reason you can't use the build.xml we've already provided for those that need to bootstrap? Hopefully that would simplify things for you. Since we have to package the sub-modules separately, we can't use the provided build.xml. Building via mvn ant:ant too isn't a much of a problem. But these test failures is a concern. Thanks for the help! --Kasun - Brett On 19/06/2011, at 4:34 PM, Kasun Gajasinghe wrote: Hi, We are in the process of integrating Maven in to Gentoo. Currently, we are trying to bootstrap maven. Our strategy is to integrate each and every sub-project of Maven-2.2.1 [1] separately. So, we first transformed these to an ant projects by generating the build.xml via `mvn ant:ant`. I know that Maven provides a build.xml in the parent, but we have to integrate each and every project separately. We will be moving to 3.x after 2.x is complete. We chose 2.x as it's much stable, and is much popular currently. So far, we have successfully integrated project up-to maven-core in the build order. But, we are encountering an issue in maven-core. When invoked via mvn (mvn install), it passes the tests successfully (obviously!). But when I invoke the project via ant, a test fails with an ERROR. I'm sending this to the dev group thinking this error is probably obvious to you all. ==**=== test: [mkdir] Created dir: /gentoo-sources/maven/maven-2/**tags/maven-2.2.1/maven-core-2.** 2.1/target/test-reports [junit] Running org.apache.maven.**WagonSelectorTest [junit] Testsuite: org.apache.maven.**WagonSelectorTest [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.361 sec [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.361 sec [junit] [junit] Testcase: testSelectHttpWagonFromDefault took 0.358 sec [junit] Caused an ERROR [junit] Error starting container [junit] org.codehaus.plexus.**PlexusContainerException: Error starting container [junit] at org.codehaus.plexus.**DefaultPlexusContainer.start(** DefaultPlexusContainer.java:**795) [junit] at org.codehaus.plexus.**PlexusTestCase.setUp(**PlexusTestCase.java:121) [junit] at org.apache.maven.**WagonSelectorTest.setUp(**WagonSelectorTest.java:76) [junit] Caused by: org.codehaus.plexus.component.**repository.exception.** ComponentRepositoryException: Component descriptor role: 'org.sonatype.plexus.**components.sec.dispatcher.**SecDispatcher', implementation: 'org.sonatype.plexus.**components.sec.dispatcher.** DefaultSecDispatcher', role hint: 'maven' has a hint, but there are other implementations that don't [junit] at org.codehaus.plexus.component.**repository.** DefaultComponentRepository.**addComponentDescriptor(** DefaultComponentRepository.**java:184) [junit] at
Re: [VOTE]: release maven-changes-plugin 2.6
Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Really? And what in your opinion would be the threshold for a release? 5 issues? 16? And if there are no open issues left, do we have to wait for people to find 8 more before we can release it? Seriously, I think this posting will easily make it on our list of 10 most pointless contributions of the year. When to call a vote for a release is solely the decision of the release manager, and the number of issues is simply irrelevant. -Lukas Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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]: release maven-changes-plugin 2.6
-Original Message- From: Lukas Theussl [mailto:ltheu...@gmail.com] On Behalf Of Lukas Theussl Sent: Monday, 20 June 2011 7:25 PM To: Maven Developers List Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Really? And what in your opinion would be the threshold for a release? 5 issues? 16? And if there are no open issues left, do we have to wait for people to find 8 more before we can release it? Depends on the quality and quantity, whether it fixes a security issue, introduces a new must have feature, etc. I would happily vote +1 for a one line security fix. Context is everything. Seriously, I think this posting will easily make it on our list of 10 most pointless contributions of the year. Do not criticise me for making a vote statement. It was not a contribution, it was a statement regarding the vote, which anyone is entitled to do. When to call a vote for a release is solely the decision of the release manager, and the number of issues is simply irrelevant. Of course, but am I not entitled to express my vote and supporting statement, or are all votes expected to be +1 with no comments. What do you base your vote on exactly? Rolling a new release for a few lines of code that fixes a couple of bugs and does not introduce any new functionality is overkill IMHO. But I will stay out of such votes/threads/opinions in the future , do what I joined this list for, then leave when I'm done. Gav... -Lukas Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQue ry= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing- releases.htm l Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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]: release maven-changes-plugin 2.6
On 20 June 2011 10:48, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Lukas Theussl [mailto:ltheu...@gmail.com] On Behalf Of Lukas Theussl Sent: Monday, 20 June 2011 7:25 PM To: Maven Developers List Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Really? And what in your opinion would be the threshold for a release? 5 issues? 16? And if there are no open issues left, do we have to wait for people to find 8 more before we can release it? Depends on the quality and quantity, whether it fixes a security issue, introduces a new must have feature, etc. I would happily vote +1 for a one line security fix. Context is everything. Seriously, I think this posting will easily make it on our list of 10 most pointless contributions of the year. Do not criticise me for making a vote statement. It was not a contribution, it was a statement regarding the vote, which anyone is entitled to do. When to call a vote for a release is solely the decision of the release manager, and the number of issues is simply irrelevant. Of course, but am I not entitled to express my vote and supporting statement, or are all votes expected to be +1 with no comments. You are entitled to express your vote and supporting statement, but the vote is expected to be based on whether the artifacts are releasable or not. So if for example you identify an issue with the built software, that could be a -1 or -0. Note that you cannot veto releases. A -1 can be ignored by the release manager. What do you base your vote on exactly? There are strict criteria for the PMC on which we are supposed to base our vote on. There are legal requirements that mandate that any release from Apache must have at least three +1 votes from the PMC for that Apache project. Each voting PMC member is required to ensure that releases meet the following: * Every ASF release must contain a source package, which must be sufficient for a user to build and test the release provided they have access to the appropriate platform and tools. The source package must be cryptographically signed by the Release Manager with a detached signature; and that package together with its signature must be tested prior to voting +1 for release. Folks who vote +1 for release may offer their own cryptographic signature to be concatenated with the detached signature file (at the Release Manager's discretion) prior to release. * Note that the PMC is responsible for all artifacts in their distribution directory, which is a subdirectory of www.apache.org/dist/ ; and all artifacts placed in their directory must be signed by a committer, preferably by a PMC member. It is also necessary for the PMC to ensure that the source package is sufficient to build any binary artifacts associated with the release. * Every ASF release must comply with ASF licensing policy. This requirement is of utmost importance and an audit should be performed before any full release is created. In particular, every artifact distributed must contain appropriate LICENSE and NOTICE files. More information can be found in the foundation website and in the release licensing FAQ. Rolling a new release for a few lines of code that fixes a couple of bugs and does not introduce any new functionality is overkill IMHO. There are a lot of companies out there who will make their employees jump through hoops if they want to built with a patched version of build tools that has not come from the build tool's distributor. Thus to help those people often times it is necessary to roll a release with the few lines of code as the issue _IS_BLOCKING_TO_THEM_ might be non-blocking to everyone else. We want people to play nice by the community. So please remember that often times these things are done to support the community. What people do not like is when the efforts of volunteers are criticized for not being enough work... we are not paid for doing this work, we do this in our spare time. Sometimes we get abuse from our spouses for working on this in our spare time... if all we have time to to is roll out a release with one minor (to you) fix, and no fixes for the issue you have... well why don't you STEP UP and provide a patch for that issue, and you know what, a committer might just pick up that patch and apply the patch and roll a release with that one minor (to them) fix included. But I will stay out of such votes/threads/opinions in the future , do what I joined this list for, then leave when I'm done. Actually, don't.
When to make a release of a Maven component / plugin
Recently a release vote received some criticism about whether the release candidate contained sufficient changes to deserve a release. Here is my position as a member of the Maven PMC. If you are a Maven Committer and you think that a specific plugin / component has a change which _you_ are prepared to spend _your_ time and effort to make a release of that plugin / component... then that change deserves a release. The above is really the only criteria about when to make a release. Obviously to make a release the unit and integration tests must be passing, but as to the scope of changes before you trigger the decision to make a release, that is entirely down to you deciding that you have the time to spend on making the release right now. If you develop a habit of making lots of frequent releases of the same plugin / component with very small changes in-between... you may find that the PMC members review your releases with decreasing priority and you might have to ping after 72h to get to the magic three +1 votes... or you may receive a mail from a PMC member asking that you slow the releases down a bit... but remember that it is better to ask forgiveness in such cases rather than worry and delay a possible release (who knows you might not have the time to make the release next week, and the changes might be a blocking issue for some user out there) In an ideal world, each of the Maven plugins / components would receive a maintenance release (if they have changes) every 6-8 weeks... we are not even close to that 24 plugins had their last release in 2010 6 plugins had their last release in 2009 3 plugins had their last release in 2008 2 plugins had their last release in 2007 And I have not even mentioned the shared components. So if you are a committer, here is a message from your PMC. If you think it needs a release, it needs a release. If after 5-10+ releases from you we think your bar for needing a release is too low, then we will tell you to raise your bar, but don't let fear of a quiet ping from the PMC prevent you from getting those 5-10+ releases out there first -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
Gavin, When you sent your message containing the words, ignore me, I was planning to take you at your word. But since you seem to have continued to continue your campaign of sneer here I guess I'll respond. 1: As it turned out, the vote that started all this concerned 10 issues. I was misled by a JIRA feature. 2: The amount of developer work that goes in is not proportional to the number of JIRAs that come out. 3: The amount of user value that comes out is not proportional to the number of JIRAs that go in. 4: An Apache principle is to encourage people to scratch their itches. This doesn't work if the change you desperately need gets trapped for months waiting for a release. Or, worse, if you get 'held hostage' by demands to fix additional problems that you don't have the expertise to tackle a the price of a release of what you need to fix. All in all, it is very handy that Maven has an automated release process that takes the RM 5 minutes and some PMC members a few more to validate his or her work. This lowers the activation energy. Is there some particular reason why you've chosen to blow a whistle about this particular question? --benson On Mon, Jun 20, 2011 at 6:08 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 20 June 2011 10:48, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Lukas Theussl [mailto:ltheu...@gmail.com] On Behalf Of Lukas Theussl Sent: Monday, 20 June 2011 7:25 PM To: Maven Developers List Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Really? And what in your opinion would be the threshold for a release? 5 issues? 16? And if there are no open issues left, do we have to wait for people to find 8 more before we can release it? Depends on the quality and quantity, whether it fixes a security issue, introduces a new must have feature, etc. I would happily vote +1 for a one line security fix. Context is everything. Seriously, I think this posting will easily make it on our list of 10 most pointless contributions of the year. Do not criticise me for making a vote statement. It was not a contribution, it was a statement regarding the vote, which anyone is entitled to do. When to call a vote for a release is solely the decision of the release manager, and the number of issues is simply irrelevant. Of course, but am I not entitled to express my vote and supporting statement, or are all votes expected to be +1 with no comments. You are entitled to express your vote and supporting statement, but the vote is expected to be based on whether the artifacts are releasable or not. So if for example you identify an issue with the built software, that could be a -1 or -0. Note that you cannot veto releases. A -1 can be ignored by the release manager. What do you base your vote on exactly? There are strict criteria for the PMC on which we are supposed to base our vote on. There are legal requirements that mandate that any release from Apache must have at least three +1 votes from the PMC for that Apache project. Each voting PMC member is required to ensure that releases meet the following: * Every ASF release must contain a source package, which must be sufficient for a user to build and test the release provided they have access to the appropriate platform and tools. The source package must be cryptographically signed by the Release Manager with a detached signature; and that package together with its signature must be tested prior to voting +1 for release. Folks who vote +1 for release may offer their own cryptographic signature to be concatenated with the detached signature file (at the Release Manager's discretion) prior to release. * Note that the PMC is responsible for all artifacts in their distribution directory, which is a subdirectory of www.apache.org/dist/ ; and all artifacts placed in their directory must be signed by a committer, preferably by a PMC member. It is also necessary for the PMC to ensure that the source package is sufficient to build any binary artifacts associated with the release. * Every ASF release must comply with ASF licensing policy. This requirement is of utmost importance and an audit should be performed before any full release is created. In particular, every artifact distributed must contain appropriate LICENSE and NOTICE files. More information can be found in the foundation website and in the release licensing FAQ. Rolling a new release for a few lines of code that fixes a couple of bugs and
RE: [VOTE]: release maven-changes-plugin 2.6
-Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Monday, 20 June 2011 9:00 PM To: Maven Developers List Cc: ga...@16degrees.com.au Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin, When you sent your message containing the words, ignore me, I was planning to take you at your word. But since you seem to have continued to continue your campaign of sneer here I guess I'll respond. 1: As it turned out, the vote that started all this concerned 10 issues. I was misled by a JIRA feature. Sure, understandable, I too followed the link you gave as part of the vote. 2: The amount of developer work that goes in is not proportional to the number of JIRAs that come out. I'm not sure I mentioned anything about this. 3: The amount of user value that comes out is not proportional to the number of JIRAs that go in. I'm not sure I mentioned anything about this. 4: An Apache principle is to encourage people to scratch their itches. After 6 years at Apache I get that. This doesn't work if the change you desperately need gets trapped for months waiting for a release. Or, worse, if you get 'held hostage' by demands to fix additional problems that you don't have the expertise to tackle a the price of a release of what you need to fix. I don’t get how this is relevant to my voting on the specifics of a few lines of changed code. I was basing this on the link you gave to the 3 Jira Issues. We now know it was 10 issues. All in all, it is very handy that Maven has an automated release process that takes the RM 5 minutes and some PMC members a few more to validate his or her work. This lowers the activation energy. That’s good, someone else in this thread earlier was making out it’s a really hard process and so therefore why would anyone do it for the sake of it. Glad to be corrected there. Is there some particular reason why you've chosen to blow a whistle about this particular question? This was no vendetta, no campaign of sneer, nothing against yourself, I know what you do it Apache and where, you work hard, do not take this as anything other than querying why would anyone do a release based on 3 issues and a few lines of code. It was just that , no more, no less, I do not get all the hostility that has come from such a query, than one is entitled to do. Please, let s drop this, I have now unsubscribed from the list. Gav... --benson On Mon, Jun 20, 2011 at 6:08 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 20 June 2011 10:48, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Lukas Theussl [mailto:ltheu...@gmail.com] On Behalf Of Lukas Theussl Sent: Monday, 20 June 2011 7:25 PM To: Maven Developers List Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Really? And what in your opinion would be the threshold for a release? 5 issues? 16? And if there are no open issues left, do we have to wait for people to find 8 more before we can release it? Depends on the quality and quantity, whether it fixes a security issue, introduces a new must have feature, etc. I would happily vote +1 for a one line security fix. Context is everything. Seriously, I think this posting will easily make it on our list of 10 most pointless contributions of the year. Do not criticise me for making a vote statement. It was not a contribution, it was a statement regarding the vote, which anyone is entitled to do. When to call a vote for a release is solely the decision of the release manager, and the number of issues is simply irrelevant. Of course, but am I not entitled to express my vote and supporting statement, or are all votes expected to be +1 with no comments. You are entitled to express your vote and supporting statement, but the vote is expected to be based on whether the artifacts are releasable or not. So if for example you identify an issue with the built software, that could be a -1 or -0. Note that you cannot veto releases. A -1 can be ignored by the release manager. What do you base your vote on exactly? There are strict criteria for the PMC on which we are supposed to base our vote on. There are legal requirements that mandate that any release from Apache must have at least three +1 votes from the PMC for that Apache project. Each voting PMC member is required to ensure that releases meet the following: * Every ASF release
Re: [VOTE]: release maven-changes-plugin 2.6
Gavin, Since I seem to have misread your tone, I apologize. --benson On Mon, Jun 20, 2011 at 7:53 AM, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Monday, 20 June 2011 9:00 PM To: Maven Developers List Cc: ga...@16degrees.com.au Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin, When you sent your message containing the words, ignore me, I was planning to take you at your word. But since you seem to have continued to continue your campaign of sneer here I guess I'll respond. 1: As it turned out, the vote that started all this concerned 10 issues. I was misled by a JIRA feature. Sure, understandable, I too followed the link you gave as part of the vote. 2: The amount of developer work that goes in is not proportional to the number of JIRAs that come out. I'm not sure I mentioned anything about this. 3: The amount of user value that comes out is not proportional to the number of JIRAs that go in. I'm not sure I mentioned anything about this. 4: An Apache principle is to encourage people to scratch their itches. After 6 years at Apache I get that. This doesn't work if the change you desperately need gets trapped for months waiting for a release. Or, worse, if you get 'held hostage' by demands to fix additional problems that you don't have the expertise to tackle a the price of a release of what you need to fix. I don’t get how this is relevant to my voting on the specifics of a few lines of changed code. I was basing this on the link you gave to the 3 Jira Issues. We now know it was 10 issues. All in all, it is very handy that Maven has an automated release process that takes the RM 5 minutes and some PMC members a few more to validate his or her work. This lowers the activation energy. That’s good, someone else in this thread earlier was making out it’s a really hard process and so therefore why would anyone do it for the sake of it. Glad to be corrected there. Is there some particular reason why you've chosen to blow a whistle about this particular question? This was no vendetta, no campaign of sneer, nothing against yourself, I know what you do it Apache and where, you work hard, do not take this as anything other than querying why would anyone do a release based on 3 issues and a few lines of code. It was just that , no more, no less, I do not get all the hostility that has come from such a query, than one is entitled to do. Please, let s drop this, I have now unsubscribed from the list. Gav... --benson On Mon, Jun 20, 2011 at 6:08 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 20 June 2011 10:48, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Lukas Theussl [mailto:ltheu...@gmail.com] On Behalf Of Lukas Theussl Sent: Monday, 20 June 2011 7:25 PM To: Maven Developers List Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Really? And what in your opinion would be the threshold for a release? 5 issues? 16? And if there are no open issues left, do we have to wait for people to find 8 more before we can release it? Depends on the quality and quantity, whether it fixes a security issue, introduces a new must have feature, etc. I would happily vote +1 for a one line security fix. Context is everything. Seriously, I think this posting will easily make it on our list of 10 most pointless contributions of the year. Do not criticise me for making a vote statement. It was not a contribution, it was a statement regarding the vote, which anyone is entitled to do. When to call a vote for a release is solely the decision of the release manager, and the number of issues is simply irrelevant. Of course, but am I not entitled to express my vote and supporting statement, or are all votes expected to be +1 with no comments. You are entitled to express your vote and supporting statement, but the vote is expected to be based on whether the artifacts are releasable or not. So if for example you identify an issue with the built software, that could be a -1 or -0. Note that you cannot veto releases. A -1 can be ignored by the release manager. What do you base your vote on exactly? There are strict criteria for the PMC on which we are supposed to base our vote on. There are legal requirements that mandate that any release from Apache must have
Re: [VOTE]: release maven-changes-plugin 2.6
Gavin, Don't take it personal. I have expressed my opinion like you have expressed yours, and we are both entitled to do so. But you have to realize that your comments were taken with offence by some developers. I have been with maven for several years now, I know we have taken criticism for not releasing often enough, for releasing incomplete stuff, for releasing broken stuff, for releasing undocumented stuff; but this is the first time I remember that we take some heat for releasing too often. I guess I simply still have to learn how to deal with it! :) -Lukas Gavin McDonald wrote: -Original Message- From: Lukas Theussl [mailto:ltheu...@gmail.com] On Behalf Of Lukas Theussl Sent: Monday, 20 June 2011 7:25 PM To: Maven Developers List Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Really? And what in your opinion would be the threshold for a release? 5 issues? 16? And if there are no open issues left, do we have to wait for people to find 8 more before we can release it? Depends on the quality and quantity, whether it fixes a security issue, introduces a new must have feature, etc. I would happily vote +1 for a one line security fix. Context is everything. Seriously, I think this posting will easily make it on our list of 10 most pointless contributions of the year. Do not criticise me for making a vote statement. It was not a contribution, it was a statement regarding the vote, which anyone is entitled to do. When to call a vote for a release is solely the decision of the release manager, and the number of issues is simply irrelevant. Of course, but am I not entitled to express my vote and supporting statement, or are all votes expected to be +1 with no comments. What do you base your vote on exactly? Rolling a new release for a few lines of code that fixes a couple of bugs and does not introduce any new functionality is overkill IMHO. But I will stay out of such votes/threads/opinions in the future , do what I joined this list for, then leave when I'm done. Gav... -Lukas Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQue ry= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing- releases.htm l Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Monday, 20 June 2011 9:00 PM To: Maven Developers List Cc: ga...@16degrees.com.au Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin, When you sent your message containing the words, ignore me, I was planning to take you at your word. But since you seem to have continued to continue your campaign of sneer here I guess I'll respond. 1: As it turned out, the vote that started all this concerned 10 issues. I was misled by a JIRA feature. Sure, understandable, I too followed the link you gave as part of the vote. 2: The amount of developer work that goes in is not proportional to the number of JIRAs that come out. I'm not sure I mentioned anything about this. ... 3 issues seems like doing a days work ... quoted from http://www.mail-archive.com/dev@maven.apache.org/msg88624.html 3: The amount of user value that comes out is not proportional to the number of JIRAs that go in. I'm not sure I mentioned anything about this. ... Don’t release for the sake of releasing... quoted from http://www.mail-archive.com/dev@maven.apache.org/msg88586.html -Lukas 4: An Apache principle is to encourage people to scratch their itches. After 6 years at Apache I get that. This doesn't work if the change you desperately need gets trapped for months waiting for a release. Or, worse, if you get 'held hostage' by demands to fix additional problems that you don't have the expertise to tackle a the price of a release of what you need to fix. I don’t get how this is relevant to my voting on the specifics of a few lines of changed code. I was basing this on the link you gave to the 3 Jira Issues. We now know it was 10 issues. All in all, it is very handy that Maven has an automated release process that takes the RM 5 minutes and some PMC members a few more to validate his or her work. This lowers the activation energy. That’s good, someone else in this thread earlier was making out it’s a really hard process and so therefore why would anyone do it for the sake of it. Glad to be corrected there. Is there some particular reason why you've chosen to blow a whistle about this particular question? This was no vendetta, no campaign of sneer, nothing against yourself, I know what you do it Apache and where, you work hard, do not take this as anything other than querying why would anyone do a release based on 3 issues and a few lines of code. It was just that , no more, no less, I do not get all the hostility that has come from such a query, than one is entitled to do. Please, let s drop this, I have now unsubscribed from the list. Gav... --benson On Mon, Jun 20, 2011 at 6:08 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 20 June 2011 10:48, Gavin McDonaldga...@16degrees.com.au wrote: -Original Message- From: Lukas Theussl [mailto:ltheu...@gmail.com] On Behalf Of Lukas Theussl Sent: Monday, 20 June 2011 7:25 PM To: Maven Developers List Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Really? And what in your opinion would be the threshold for a release? 5 issues? 16? And if there are no open issues left, do we have to wait for people to find 8 more before we can release it? Depends on the quality and quantity, whether it fixes a security issue, introduces a new must have feature, etc. I would happily vote +1 for a one line security fix. Context is everything. Seriously, I think this posting will easily make it on our list of 10 most pointless contributions of the year. Do not criticise me for making a vote statement. It was not a contribution, it was a statement regarding the vote, which anyone is entitled to do. When to call a vote for a release is solely the decision of the release manager, and the number of issues is simply irrelevant. Of course, but am I not entitled to express my vote and supporting statement, or are all votes expected to be +1 with no comments. You are entitled to express your vote and supporting statement, but the vote is expected to be based on whether the artifacts are releasable or not. So if for example you identify an issue with the built software, that could be a -1 or -0. Note that you cannot veto releases. A -1 can be ignored by the release manager. What do you base your vote on exactly? There are strict criteria for the PMC on which we are supposed to base our vote on. There are legal requirements that mandate that any release from Apache must have at least three +1
Re: When to make a release of a Maven component / plugin
Hi, I'm no Maven PMC member, but please don't care about the kind of recent mail that was recently received here. This was only clueless flaming, not well-thought and constructive critics that would have had a chance to improve something. Having frequent releases is a good thing for people to see the project is well alive. Release early, release often is a good policy. Small is beautiful, too. Please keep up the good work. Thanks everyone for your time. Really, it's appreciated. You are heroes :-). Cheers. Baptiste 6/20 Stephen Connolly steph...@apache.org Recently a release vote received some criticism about whether the release candidate contained sufficient changes to deserve a release. Here is my position as a member of the Maven PMC. If you are a Maven Committer and you think that a specific plugin / component has a change which _you_ are prepared to spend _your_ time and effort to make a release of that plugin / component... then that change deserves a release. The above is really the only criteria about when to make a release. Obviously to make a release the unit and integration tests must be passing, but as to the scope of changes before you trigger the decision to make a release, that is entirely down to you deciding that you have the time to spend on making the release right now. If you develop a habit of making lots of frequent releases of the same plugin / component with very small changes in-between... you may find that the PMC members review your releases with decreasing priority and you might have to ping after 72h to get to the magic three +1 votes... or you may receive a mail from a PMC member asking that you slow the releases down a bit... but remember that it is better to ask forgiveness in such cases rather than worry and delay a possible release (who knows you might not have the time to make the release next week, and the changes might be a blocking issue for some user out there) In an ideal world, each of the Maven plugins / components would receive a maintenance release (if they have changes) every 6-8 weeks... we are not even close to that 24 plugins had their last release in 2010 6 plugins had their last release in 2009 3 plugins had their last release in 2008 2 plugins had their last release in 2007 And I have not even mentioned the shared components. So if you are a committer, here is a message from your PMC. If you think it needs a release, it needs a release. If after 5-10+ releases from you we think your bar for needing a release is too low, then we will tell you to raise your bar, but don't let fear of a quiet ping from the PMC prevent you from getting those 5-10+ releases out there first -Stephen - To unsubscribe, e-mail: dev-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 !
Missing javax.servlet:jstl:1.2
The artifacts for javax.servlet:jstl:1.2 seem to have disappeared from central [1]. They still appear in the Sonatype search [2]. Does anyone know what happened to these files? Were they removed because of a bad license or something? [1]http://repo1.maven.org/maven2/javax/servlet/jstl/ [2]http://search.maven.org/#search|gav|1|g%3A%22javax.servlet%22%20AND%20a%3A%22jstl%22 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Missing javax.servlet:jstl:1.2
It seems that the artifacts were moved to a different location: https://issues.sonatype.org/browse/MVNCENTRAL-71 On 06/20/2011 10:41 AM, Paul Gier wrote: The artifacts for javax.servlet:jstl:1.2 seem to have disappeared from central [1]. They still appear in the Sonatype search [2]. Does anyone know what happened to these files? Were they removed because of a bad license or something? [1]http://repo1.maven.org/maven2/javax/servlet/jstl/ [2]http://search.maven.org/#search|gav|1|g%3A%22javax.servlet%22%20AND%20a%3A%22jstl%22 - 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: Missing javax.servlet:jstl:1.2
I though artifacts were supposed to never change at central... This could break people's builds. /Anders On Mon, Jun 20, 2011 at 19:00, Paul Gier pg...@redhat.com wrote: It seems that the artifacts were moved to a different location: https://issues.sonatype.org/browse/MVNCENTRAL-71 On 06/20/2011 10:41 AM, Paul Gier wrote: The artifacts for javax.servlet:jstl:1.2 seem to have disappeared from central [1]. They still appear in the Sonatype search [2]. Does anyone know what happened to these files? Were they removed because of a bad license or something? [1]http://repo1.maven.org/maven2/javax/servlet/jstl/ [2] http://search.maven.org/#search|gav|1|g%3A%22javax.servlet%22%20AND%20a%3A%22jstl%22http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22javax.servlet%22%20AND%20a%3A%22jstl%22 - 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: Missing javax.servlet:jstl:1.2
actually I think javax.jstl NEVER have been on maven.central. It originally was hosted on java.net, but they killed parts of their maven repo while migrating from sun to oracle. There is of course an ALv2 version of jstl: http://repo1.maven.org/maven2/org/apache/geronimo/bundles/jstl/1.2_1/ LieGrue, strub --- On Mon, 6/20/11, Anders Hammar and...@hammar.net wrote: From: Anders Hammar and...@hammar.net Subject: Re: Missing javax.servlet:jstl:1.2 To: Maven Developers List dev@maven.apache.org Date: Monday, June 20, 2011, 5:26 PM I though artifacts were supposed to never change at central... This could break people's builds. /Anders On Mon, Jun 20, 2011 at 19:00, Paul Gier pg...@redhat.com wrote: It seems that the artifacts were moved to a different location: https://issues.sonatype.org/browse/MVNCENTRAL-71 On 06/20/2011 10:41 AM, Paul Gier wrote: The artifacts for javax.servlet:jstl:1.2 seem to have disappeared from central [1]. They still appear in the Sonatype search [2]. Does anyone know what happened to these files? Were they removed because of a bad license or something? [1]http://repo1.maven.org/maven2/javax/servlet/jstl/ [2] http://search.maven.org/#search|gav|1|g%3A%22javax.servlet%22%20AND%20a%3A%22jstl%22http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22javax.servlet%22%20AND%20a%3A%22jstl%22 - 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
REMINDER: Participation Requested: Survey about Open-Source Software Development
Hi, Apologies for any inconvenience and thank you to those who have already completed the survey. We will keep the survey open for another couple of weeks. But, we do hope you will consider responding to the email request below (sent 2 weeks ago). Thanks, Dr. Jeffrey Carver Assistant Professor University of Alabama (v) 205-348-9829 (f) 205-348-0219 http://www.cs.ua.edu/~carver -Original Message- From: Jeffrey Carver [mailto:opensourcesur...@cs.ua.edu] Sent: Monday, June 13, 2011 11:24 AM To: 'dev@maven.apache.org' Subject: Participation Requested: Survey about Open-Source Software Development Hi, Drs. Jeffrey Carver, Rosanna Guadagno, Debra McCallum, and Mr. Amiangshu Bosu, University of Alabama, and Dr. Lorin Hochstein, University of Southern California, are conducting a survey of open-source software developers. This survey seeks to understand how developers on distributed, virtual teams, like open-source projects, interact with each other to accomplish their tasks. You must be at least 19 years of age to complete the survey. The survey should take approximately 15 minutes to complete. If you are actively participating as a developer, please consider completing our survey. Here is the link to the survey: http://goo.gl/HQnux We apologize for inconvenience and if you receive multiple copies of this email. This survey has been approved by The University of Alabama IRB board. Thanks, Dr. Jeffrey Carver Assistant Professor University of Alabama (v) 205-348-9829 (f) 205-348-0219 http://www.cs.ua.edu/~carver - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
Wow - that seems like a hell of a lot of releases having to be made... This post is probably drifting off topic but the thing that strikes me here is that this is the exact reason why maven supports version ranges - so that you don't have to make a plethora of rolling releases just because one change was made downstream. It's no wonder a lot of version range bugs in maven never get fixed if none of the plugins or maven itself actually uses them. Of course this only solves the problem where an upstream release contains non-breaking changes for its downstream users which hopefully, for bug fixes would be more often than not. Locking down versions is good for third party dependencies, but I'm very much of the mind that ranges should be used for sibings, would certainly solve the problem of transitive release blowouts. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Den 19.06.2011 23:08, skrev Gavin McDonald: I would be happy with weeks to be honest. Then again I have been used to being around slower projects that have released only every 2 or 3 years once 1 or 2 hundred issues have been gathered into a release. And the release process itself takes weeks of work to achieve. Therefore ignore me, 3 issues seems like doing a days work, then release, then another days work, then release etc ... Given a very quick count, the apache maven project contains something like 90 individually deployable and separately votable artifacts. Our users upgrade these components individually according to need. Each component is individually tested and voted for; maven is not a monolithic application and should not be released as one. The downside of this componentization is that sometimes fixing a single issue leads to the redeployment of multiple artifacts, at the moment I'm working on 1 issue that will require the redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere) before it's closed in its full extent. Most likely I'll have votes for 2 of these soon and I'll just let the remaining 4 roll out together with releases planned by others. But in this context I simply refuse to consider if a single release vote is too large or too small. From an agile perspective there's potential to getting a lot more issues fixed with a single year than the kind of project you mention. I have no specific stats but I assume we fix at least a thousand issues every year. Some of our projects have sufficiently good automated test coverage that I suspect we could allow incremental .1 releases to go without a vote entirely. I'm not sure if this is something we're even allowed to consider ;) (Surefire would probably qualify, assuming we did some kind of formalized continious production kind of review) I think ideally we should release every top-level component every 6 weeks or so. But that means we'd have 1-3 votes every day ;) Kristian --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
Mark, maybe this is not so obvious, but Maven internally has ClassLoader isolation between plugins. This is comparable to a servlet container where 1 webapp only can see its own classes. This way it is no problem that there are more versions of a plugin (or any other dependency) being used in the same maven build. LieGrue, strub --- On Mon, 6/20/11, Mark Derricutt m...@talios.com wrote: From: Mark Derricutt m...@talios.com Subject: Re: [VOTE]: release maven-changes-plugin 2.6 To: Maven Developers List dev@maven.apache.org Date: Monday, June 20, 2011, 8:27 PM Wow - that seems like a hell of a lot of releases having to be made... This post is probably drifting off topic but the thing that strikes me here is that this is the exact reason why maven supports version ranges - so that you don't have to make a plethora of rolling releases just because one change was made downstream. It's no wonder a lot of version range bugs in maven never get fixed if none of the plugins or maven itself actually uses them. Of course this only solves the problem where an upstream release contains non-breaking changes for its downstream users which hopefully, for bug fixes would be more often than not. Locking down versions is good for third party dependencies, but I'm very much of the mind that ranges should be used for sibings, would certainly solve the problem of transitive release blowouts. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Den 19.06.2011 23:08, skrev Gavin McDonald: I would be happy with weeks to be honest. Then again I have been used to being around slower projects that have released only every 2 or 3 years once 1 or 2 hundred issues have been gathered into a release. And the release process itself takes weeks of work to achieve. Therefore ignore me, 3 issues seems like doing a days work, then release, then another days work, then release etc ... Given a very quick count, the apache maven project contains something like 90 individually deployable and separately votable artifacts. Our users upgrade these components individually according to need. Each component is individually tested and voted for; maven is not a monolithic application and should not be released as one. The downside of this componentization is that sometimes fixing a single issue leads to the redeployment of multiple artifacts, at the moment I'm working on 1 issue that will require the redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere) before it's closed in its full extent. Most likely I'll have votes for 2 of these soon and I'll just let the remaining 4 roll out together with releases planned by others. But in this context I simply refuse to consider if a single release vote is too large or too small. From an agile perspective there's potential to getting a lot more issues fixed with a single year than the kind of project you mention. I have no specific stats but I assume we fix at least a thousand issues every year. Some of our projects have sufficiently good automated test coverage that I suspect we could allow incremental .1 releases to go without a vote entirely. I'm not sure if this is something we're even allowed to consider ;) (Surefire would probably qualify, assuming we did some kind of formalized continious production kind of review) I think ideally we should release every top-level component every 6 weeks or so. But that means we'd have 1-3 votes every day ;) Kristian --**--**- 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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
(Other) Mark, I'm not sure I see the connection here? Lukas had made comment that making one release would trigger cascading releases, which I assume is because downstream plugins have fixed version number dependencies. However if those dependencies were [1.0,2.0) then they would use the most recent automatically without having to rerelease everything. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Tue, Jun 21, 2011 at 8:39 AM, Mark Struberg strub...@yahoo.de wrote: Mark, maybe this is not so obvious, but Maven internally has ClassLoader isolation between plugins. This is comparable to a servlet container where 1 webapp only can see its own classes. This way it is no problem that there are more versions of a plugin (or any other dependency) being used in the same maven build. LieGrue, strub --- On Mon, 6/20/11, Mark Derricutt m...@talios.com wrote: From: Mark Derricutt m...@talios.com Subject: Re: [VOTE]: release maven-changes-plugin 2.6 To: Maven Developers List dev@maven.apache.org Date: Monday, June 20, 2011, 8:27 PM Wow - that seems like a hell of a lot of releases having to be made... This post is probably drifting off topic but the thing that strikes me here is that this is the exact reason why maven supports version ranges - so that you don't have to make a plethora of rolling releases just because one change was made downstream. It's no wonder a lot of version range bugs in maven never get fixed if none of the plugins or maven itself actually uses them. Of course this only solves the problem where an upstream release contains non-breaking changes for its downstream users which hopefully, for bug fixes would be more often than not. Locking down versions is good for third party dependencies, but I'm very much of the mind that ranges should be used for sibings, would certainly solve the problem of transitive release blowouts. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Den 19.06.2011 23:08, skrev Gavin McDonald: I would be happy with weeks to be honest. Then again I have been used to being around slower projects that have released only every 2 or 3 years once 1 or 2 hundred issues have been gathered into a release. And the release process itself takes weeks of work to achieve. Therefore ignore me, 3 issues seems like doing a days work, then release, then another days work, then release etc ... Given a very quick count, the apache maven project contains something like 90 individually deployable and separately votable artifacts. Our users upgrade these components individually according to need. Each component is individually tested and voted for; maven is not a monolithic application and should not be released as one. The downside of this componentization is that sometimes fixing a single issue leads to the redeployment of multiple artifacts, at the moment I'm working on 1 issue that will require the redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere) before it's closed in its full extent. Most likely I'll have votes for 2 of these soon and I'll just let the remaining 4 roll out together with releases planned by others. But in this context I simply refuse to consider if a single release vote is too large or too small. From an agile perspective there's potential to getting a lot more issues fixed with a single year than the kind of project you mention. I have no specific stats but I assume we fix at least a thousand issues every year. Some of our projects have sufficiently good automated test coverage that I suspect we could allow incremental .1 releases to go without a vote entirely. I'm not sure if this is something we're even allowed to consider ;) (Surefire would probably qualify, assuming we did some kind of formalized continious production kind of review) I think ideally we should release every top-level component every 6 weeks or so. But that means we'd have 1-3 votes every day ;) Kristian --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org 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]: release maven-changes-plugin 2.6
Please make a new thread. On Mon, Jun 20, 2011 at 5:51 PM, Mark Derricutt m...@talios.com wrote: (Other) Mark, I'm not sure I see the connection here? Lukas had made comment that making one release would trigger cascading releases, which I assume is because downstream plugins have fixed version number dependencies. However if those dependencies were [1.0,2.0) then they would use the most recent automatically without having to rerelease everything. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Tue, Jun 21, 2011 at 8:39 AM, Mark Struberg strub...@yahoo.de wrote: Mark, maybe this is not so obvious, but Maven internally has ClassLoader isolation between plugins. This is comparable to a servlet container where 1 webapp only can see its own classes. This way it is no problem that there are more versions of a plugin (or any other dependency) being used in the same maven build. LieGrue, strub --- On Mon, 6/20/11, Mark Derricutt m...@talios.com wrote: From: Mark Derricutt m...@talios.com Subject: Re: [VOTE]: release maven-changes-plugin 2.6 To: Maven Developers List dev@maven.apache.org Date: Monday, June 20, 2011, 8:27 PM Wow - that seems like a hell of a lot of releases having to be made... This post is probably drifting off topic but the thing that strikes me here is that this is the exact reason why maven supports version ranges - so that you don't have to make a plethora of rolling releases just because one change was made downstream. It's no wonder a lot of version range bugs in maven never get fixed if none of the plugins or maven itself actually uses them. Of course this only solves the problem where an upstream release contains non-breaking changes for its downstream users which hopefully, for bug fixes would be more often than not. Locking down versions is good for third party dependencies, but I'm very much of the mind that ranges should be used for sibings, would certainly solve the problem of transitive release blowouts. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Den 19.06.2011 23:08, skrev Gavin McDonald: I would be happy with weeks to be honest. Then again I have been used to being around slower projects that have released only every 2 or 3 years once 1 or 2 hundred issues have been gathered into a release. And the release process itself takes weeks of work to achieve. Therefore ignore me, 3 issues seems like doing a days work, then release, then another days work, then release etc ... Given a very quick count, the apache maven project contains something like 90 individually deployable and separately votable artifacts. Our users upgrade these components individually according to need. Each component is individually tested and voted for; maven is not a monolithic application and should not be released as one. The downside of this componentization is that sometimes fixing a single issue leads to the redeployment of multiple artifacts, at the moment I'm working on 1 issue that will require the redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere) before it's closed in its full extent. Most likely I'll have votes for 2 of these soon and I'll just let the remaining 4 roll out together with releases planned by others. But in this context I simply refuse to consider if a single release vote is too large or too small. From an agile perspective there's potential to getting a lot more issues fixed with a single year than the kind of project you mention. I have no specific stats but I assume we fix at least a thousand issues every year. Some of our projects have sufficiently good automated test coverage that I suspect we could allow incremental .1 releases to go without a vote entirely. I'm not sure if this is something we're even allowed to consider ;) (Surefire would probably qualify, assuming we did some kind of formalized continious production kind of review) I think ideally we should release every top-level component every 6 weeks or so. But that means we'd have 1-3 votes every day ;) Kristian --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org 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: ranges and cascading releases was: [VOTE]: release maven-changes-plugin 2.6
Kristian can describe in more detail what he's working on, but not all changes take 8 artifact changes. In this case I think it's both that it's something that affects multiple things (rather than dependencies), and also a couple of things that have been broken down to one too separate many artifacts (like plexus-compiler, which I think is only ever used in the compiler plugin). Those sorts of exercises should actually help us understand if the right type of modularity has been applied. - Brett On 21/06/2011, at 6:27 AM, Mark Derricutt wrote: Wow - that seems like a hell of a lot of releases having to be made... This post is probably drifting off topic but the thing that strikes me here is that this is the exact reason why maven supports version ranges - so that you don't have to make a plethora of rolling releases just because one change was made downstream. It's no wonder a lot of version range bugs in maven never get fixed if none of the plugins or maven itself actually uses them. Of course this only solves the problem where an upstream release contains non-breaking changes for its downstream users which hopefully, for bug fixes would be more often than not. Locking down versions is good for third party dependencies, but I'm very much of the mind that ranges should be used for sibings, would certainly solve the problem of transitive release blowouts. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Den 19.06.2011 23:08, skrev Gavin McDonald: I would be happy with weeks to be honest. Then again I have been used to being around slower projects that have released only every 2 or 3 years once 1 or 2 hundred issues have been gathered into a release. And the release process itself takes weeks of work to achieve. Therefore ignore me, 3 issues seems like doing a days work, then release, then another days work, then release etc ... Given a very quick count, the apache maven project contains something like 90 individually deployable and separately votable artifacts. Our users upgrade these components individually according to need. Each component is individually tested and voted for; maven is not a monolithic application and should not be released as one. The downside of this componentization is that sometimes fixing a single issue leads to the redeployment of multiple artifacts, at the moment I'm working on 1 issue that will require the redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere) before it's closed in its full extent. Most likely I'll have votes for 2 of these soon and I'll just let the remaining 4 roll out together with releases planned by others. But in this context I simply refuse to consider if a single release vote is too large or too small. From an agile perspective there's potential to getting a lot more issues fixed with a single year than the kind of project you mention. I have no specific stats but I assume we fix at least a thousand issues every year. Some of our projects have sufficiently good automated test coverage that I suspect we could allow incremental .1 releases to go without a vote entirely. I'm not sure if this is something we're even allowed to consider ;) (Surefire would probably qualify, assuming we did some kind of formalized continious production kind of review) I think ideally we should release every top-level component every 6 weeks or so. But that means we'd have 1-3 votes every day ;) Kristian --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-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
