Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)
On Jul 25, 2013, at 5:05 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Perhaps we could reframe the question a little then (as people seem to be testing hung up on the committed wording)... Should the PMC encourage people experimenting on new improvements to Maven to do that work at the ASF? And if so, should they then practice what they preach, and ensure that any experiments with Maven take place on the ASF SCM servers (at least once such experiments become semi-serious or progress enough not to cause egg-on-face syndrome)? If members of the Apache Board are leading by example then the answer to your questions are clearly no. Cloudera makes a distribution of Hadoop. It definitely contains features and code that don't exist in the standard Apache distribution and this all doesn't get developed at Apache. They have to as that's one of their differentiators. I don't think this is a bad thing, I think this is a good thing. A company who has customers, who pay for Cloudera employees to work on Hadoop and I'm sure some of that work finds its way back into Hadoop. That's how healthy ecosystems work. And if you look at many of the PMCs they also have members that work at commercial companies you will also find more examples of no to both of your questions. Shoud the PMC promote other Apache projects, Blindly? With the criterion being eat your own dogfood? That, to me, would be ridiculous. Use the best library you can find regardless of where it comes from provided the license is appropriate. or moving non-Apache projects to Apache? (Right now, to work on an issue in core and effect the change yourself you may need to establish merit with: Apache Maven, Eclipse Sisu, Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be fine with half of these at Eclipse and the ther half here... Or maybe not... But that is a lot of projects where you need to establish merit and perhaps maintain merit just to be able to commit directly (which sometimes is the only way to effect the type of cross system changes that some of our more obscure bugs may require... GIT makes this less of a requirement, as patches on SVN are a PITA, though) ) Nonsense. I just got two pull requests for Polyglot Tesla in the last two days from people who are interested. If they are good patches I'll take them. Do you really think that a project is presented with a good patch the project is going to say no? Everyone talks about this mythical barrier and that it's so much work to do something not at Apache. Has anyone ever stopped you from contributing to any of the projects above? I've seen more content in the form of email about the potential of not being able to commit to these projects than code contributions actually presented to these projects. I think if someone actually tried contributing, instead of imagining why it's hard, you'd find that it's not hard. Thinking that everything has to be here to work on it is a rather provincial point of view. It doesn't mean I don't care about what I work on here, but I acknowledge that there is work outside of Apache that's useful and interesting. Anyone who actually fixes cross project issues just fixes cross project issues. Stuart is not even a committer and fixes more cross project issues than most committers here and you don't see him bemoaning the fact he doesn't have commit access. So I think that whole notion that everything has to be here in order for their to be an effective way to work on issues is complete bunk. These types of questions need resolution as they will, further down the road, rise up again and cause wounds... Eg logback vs log4j2 is one that simmers at the edge (any time anyone mentioned coloured loggers) -Stephen On Thursday, 25 July 2013, Paul Benedict wrote: I don't think it is possible to force volunteer efforts and/or limit development elsewhere. The idea of supporting a project is a vague notion. I have my opinions too but this language is clearly unenforceable and impractical. Cheers, Paul On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg k...@quipsy.de wrote: As a Maven user I think that everybody who is working on a project should behave the same. Hence, I would say, PMC members should rather certainly demonstrate how to live the community rules. -Ursprüngliche Nachricht- Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Gesendet: Donnerstag, 25. Juli 2013 15:16 An: Maven Users List; Maven Developers List Betreff: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md) There are two schools of thought amongst the current members of this projects PMC. Without wanting to deliberately tip my hand and reveal where my opinion is, we would like to solicit the opinions if the community that we serve. Please give
[RESULT] [VOTE] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+
On 23 July 2013 14:59, Stephen Connolly stephen.alan.conno...@gmail.comwrote: This vote is to cover the minimum required version of Java for Maven Core. Maven Plugins produced by the Apache Maven Project that are flagged as compatible with older versions of Maven Core as their baseline will still require to stick to the minimum Java requirements of that Maven Core version. In other words, if for example maven-compiler-plugin advertises compatibility with Maven Core 2.0.11+ then that will still need to be compiled targeting Java 1.4 and only using dependencies that are aligned with that runtime requirement. Additionally patch releases to existing releases of Maven Core will not be subject to this requirement. For example [example]*if* this vote passes and *if* on Sep 29th we release Maven 3.2.0 and *if* on Oct 2nd we release Maven 2.0.12, Maven 2.2.2, Maven 3.0.6, Maven 3.1.1, Maven 3.2.1 and Maven 3.3.0 (due to say some security issue that affected all versions of Maven) then only Maven 3.3.0 would be require Java 6 as a minimum runtime requirement, the 2.0.12 release would still require Java 1.4 and the 2.2.2, 3.0.6, 3.1.1 and 3.2.1 versions would all still require Java 1.5.[/example] This is not a requirement that 3rd party plugins need use Java 6 as a minimum. Third party plugins are free to require any Java version = the corresponding Maven minimum requirement, though obviously from a users perspective it is best if plugins try to adhere to our contracts for corresponding versions of Maven Core. Justification for the cut-off date: * Oracle has gone end of life on Java 6 Feb 2013 (note that there is still extended and sustaining support for existing Oracle customers using Java 5) * IBM will go end of life for z/OS on 30th Sep 2013 (other platforms are still with support, but there are other Java vendors for other platforms) * Apple no longer supports any hardware that does not have at least an Apple Java 6 version available. * Red Hat is providing support for OpenJDK 6 * HP-UX, OpenVMS, and Tru64 all have a Java 6 implementation available. As I see it, that essentially ensures that for the vast majority of platforms there is a very strong likelihood of a Java 6 compatible version of Java available for that platform. Toolchains support or forking of the compiler and surefire can provide support for users who still need to build with older versions of Java (e.g., as was the case for Java 1.4.2 with Maven 2.2.1). Additionally users who are forced to use a java version older than Java 6 also are likely unable to upgrade their version of Maven, so this change will not affect them This vote is open for 72 hours. A minimum of three +1 binding votes (i.e. from the PMC) and the majority of votes cast from committers will be required to pass this vote. +1000: Yes, and when can we have the vote to go for Java 7 as a minimum? (This option is equivalent to +1 but provides people the ability to indicate an additional preference while not contributing to the inevitible noise) +1: Yes 0: No opinion -1: No -Stephen Results: +1 (binding): Stephen Connolly, Arguad Héritier, Dennis Lundberg, Wayne Fay, Barrie Treloar, Kristian Rosenvold, Olivier Lamy, John Casey, Robert Scholte. +1 (committers): Tony Chemit, Anders Hammar, Tamás Cservenák, Andreas Gudian. +1 (others): Fred Cooke, Lennart Jörelid, Jeff Jensen, Paul Benedict, Baptiste Mathus, Jeff Maury, Stevo Slavic, Chris Graham, Christian Schulte, Mirko Friedenhagen. 0: Michael O We have more than three PMC +1's Of those committers who voted, the majority voted +1 (all in fact) This vote passes.
Re: Java version usage survey
As we launched the other thread about removing the Java 6 support after september I never communicated about this survey but it seems that we have some readers here as we had 180 replies without doing anything : https://docs.google.com/forms/d/1Jqxq2KgSricwS7YV7pmWvHA8m7_TE7c8JhusugPmGW4/viewanalytics Cheers, On Wed, Jul 17, 2013 at 11:59 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: That would likely be a fix that any organizations providing longer term support would likely backport for their enterprise versions of Jenkins... On 17 July 2013 10:53, Arnaud Héritier aherit...@gmail.com wrote: Note that to have the fix and be able to use Maven 3.1.0, jenkins users will have to upgrade which won't be soon for many of them (Myself I'm using the latest really stable one : the 1.480 LTS) On Wed, Jul 17, 2013 at 11:31 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 17 July 2013 10:09, Olivier Lamy ol...@apache.org wrote: 2013/7/17 Olivier Lamy ol...@apache.org: 2013/7/17 Stephen Connolly stephen.alan.conno...@gmail.com: On 16 July 2013 23:01, Arnaud Héritier aherit...@gmail.com wrote: Until Jenkins gets upgraded to 1.520+ at which point the (crappy in my personal view) Maven job type will be unable to run 1.5 The crappy one which doesn't work with Maven 3.1.0 too (I tested it this afternoon) I'm sure Olivier will rush to try and defend that job type... By defend I meant that you would go and fix it again! I am quite happy to keep bashing that job type... been bashing it since 2007 BTW and I still haven't stopped having issues with it. For example all our automated internal release builds in CloudBees cannot work with the Maven job type and need to be FreeStyle + Maven Build step due to issues in the Maven job type. KK keeps on trying to convince me that some latest change or other will redeem the Maven job type... and we spin a week trying to make it work... and we go back to FreeStyle + Maven Build step... I prefer to keep my time to maybe update it to get it working with 3.1.x rather than waste my time on mailing list discussions. Apologize if the response looks rude. I didn't take offence... I was actually trying to say that you would rush to fix the job type, so your reply was exactly in line with my thinking... hmmm perhaps my virtual Olivier simulation that I run in my head is not as inaccurate as I suspect most of my simulations are! :-P I'm probably too upset to not have tested neither take care of that before... First, I agree on the fact the Maven Integration in Jenkins is optimum especially in the case of non backward compat change in maven core. But now we have two options: 1. rewrite that but we have to build a compatibility layer for all plugins using MavenReporter extension point (and maybe having something to move datas to the new model) (probably something to discuss on jenkins-dev@) Meh! I think there is a better way... but that is because I have a different plan whereby people don't want the old integrations 2. hack the current one to make it working with 3.1.x too Perso, I don't have time for 1 (this can take a bit of time) (but I have some ideas too :-)). So at least we could take care of users and work on 2. (I already did that for 3.0.x so I can again not sure for an other time :-)) (btw thanks again to Hervé for the work on maven plugins!) Hey I'm fine with you getting the job type fixed... I have enough fun trying to duck and avoid support tickets for the job type I *hate*... ;-) Can still keep trucking with a FreeStyle + Maven Build Step though (and I prefer that way anyway) asJenkinsUser Me too if we backport features from the crappy maven integration into the freestyle job (automatic dependencies, post build deployment ..). What was done in Hudson was good from my point UI (excepted the GWT UI which was ugly) /asJenkinsUser Ahem... there are other ways to skin this cat... but the people who know have been sworn to secrecy under pain of being shot, hung, drawn and quartered before having the entire troupé of Riverdance dance on their grave... so you'll just have to wait a month of so to find out! -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail:
Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)
Le 25 juil. 2013 23:05, Stephen Connolly stephen.alan.conno...@gmail.com a écrit : Perhaps we could reframe the question a little then (as people seem to be testing hung up on the committed wording)... Should the PMC encourage people experimenting on new improvements to Maven to do that work at the ASF? Sure. I don't see how one could disagree with the statement. And if so, should they then practice what they preach, and ensure that any experiments with Maven take place on the ASF SCM servers (at least once such experiments become semi-serious or progress enough not to cause egg-on-face syndrome)? Re-reading it with *PMC member* in mind, it also makes sense. The difficulty is actually defining what is semi-serious, but anyway not sure I'd see the goal for a *pmc member* to commit his WIP outside the asf. Sure there's github's facilities to help contribution but there's already an automatic asf-github mirroring, right? Shoud the PMC promote other Apache projects, or moving non-Apache projects to Apache? (Right now, to work on an issue in core and effect the change yourself you may need to establish merit with: Apache Maven, Eclipse Sisu, Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be fine with half of these at Eclipse and the ther half here... Or maybe not... But that is a lot of projects where you need to establish merit and perhaps maintain merit just to be able to commit directly (which sometimes is the only way to effect the type of cross system changes that some of our more obscure bugs may require... GIT makes this less of a requirement, as patches on SVN are a PITA, though) ) Not sure how this one could get handled in practice. I suppose this is better to try and keep them at Apache, but using a myriad of different libs is a reality in a majority if not all java projects. To handle code issues, I think this might suffice to check the license allows a local versions be used (as Jenkins does) to be sure Maven does not get stuck because of one of those deps. I think apache projects should be preferred when there's a real equivalence between two choices. But again defining/agreeing on this can be hard. On the log4j2/logback side for example, even if I personally use logback on a daily-basis I'd understand log4j2 be chosen as a default provider because it's a apache project and the equivalence seems to be more and more a reality. Cheers -- Baptiste
[RESULT] [VOTE] Release Apache Maven IDEA Plugin version 2.2.1
Hi, The vote has passed with the following result: +1 (binding): Dennis Lundberg, Stephen Connolly, Olivier Lamy, Stephane Nicoll, Hervé Boutemy +1 (non binding): Lennart Jörelid I will promote the artifacts to the central repo. On Tue, Jul 23, 2013 at 8:23 PM, Dennis Lundberg dennisl.apa...@gmail.com wrote: Hi, This is the final release of this plugin. After this release it will be retired, see separate vote thread for more info on that. We solved 1 issue: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11135styleName=Htmlversion=14478 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11135status=1 Staging repo: https://repository.apache.org/content/repositories/maven-008/ https://repository.apache.org/content/repositories/maven-008/org/apache/maven/plugins/maven-idea-plugin/2.2.1/maven-idea-plugin-2.2.1-source-release.zip For those interested, the SCM URL can be found in the pom.xml that is in the staging repo. Staging site: http://maven.apache.org/plugins-archives/maven-idea-plugin-2.2.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Apache Maven Model Converter version 2.3
Hi, The vote has passed with the following result: +1 (binding): Olivier Lamy, Dennis Lundberg, Stephen Connolly, Hervé Boutemy I will promote the artifacts to the central repo. On Tue, Jul 23, 2013 at 9:45 PM, Dennis Lundberg denn...@apache.org wrote: Hi, This will be the final release of this shared component. After this release it will retire from the Apache Maven project and move to the Apache Archiva project. See separate vote thread about that. We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=14389 There are no issues left in JIRA (except for the one to retire, which I'll close later): http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761component=13272status=1 Staging repo: https://repository.apache.org/content/repositories/maven-010/ https://repository.apache.org/content/repositories/maven-010/org/apache/maven/shared/maven-model-converter/2.3/maven-model-converter-2.3-source-release.zip Staging site (not synced yet): http://maven.apache.org/shared-archives/maven-model-converter-2.3/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
