Re: maven errors on xml security package
Are you sure that no other Java SDK exists on your workstation? Ron On 24/07/2013 12:44 PM, Dhiman wrote: Here is code snippet for source and target but this didn't help me build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.4/version configuration source1.6/source target1.6/target /configuration /plugin /plugins /build -- View this message in context: http://maven.40175.n5.nabble.com/maven-errors-on-xml-security-package-tp117907p5765081.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
javadoc release blocking step
Hello all, During my release :perform, maven block on a javadoc instruction and I dont understand why it block indefinitely the line where my process block is: [INFO] [DEBUG] /usr/lib/jvm/jdk1.6.0_37/jre/../bin/javadoc @options @packages According to following debug log traces (in attachment), anyone know the problem ? Or how I can avoid javadoc generation ? My command is: mvn -Darguments=-Dmaven.test.skip=true -Pdistribution-packaging release:prepare release:perform --batch-mode -Dtag=Spring2013/005 -DreleaseVersion=Spring2013-005 -DdevelopmentVersion=Spring2013-006-SNAPSHOT -X Great thank and best regards Adrien - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven surefire - selecting providers
I'm still struggling - I now think that testng really is in mixed mode and tries but fails to execute the jUnit test - maybe, because they use a special runner. Is there any way to disable the mixed mode for a maven build (entirely)? How can I pass that property testng.mixed=false to testng without having to write a testng.xml file (unless it is real trivial...) Best regards, Andreas 2013/7/24 Francesco Mari mari.france...@gmail.com I still wasn't able to reproduce your issue. Looks like TestNG is running in mixed mode [1][2]. The last missing information is the version of JUnit and TestNG you are using. Can you provide this piece of configuration? [1]: http://testng.org/doc/migrating.html [2]: http://testng.org/doc/documentation-main.html#junit 2013/7/24 Andreas Dolk andreas.dolk.mo...@googlemail.com Hi Francesco, I'm using 2.15 And here's the result from a test run, that's what happens. The tests are *only* jUnit tests. I've only replaced path and package names. BTW, the jUnit times are net execution times (unfair!!), testNG reports the total times (fair) ;) The other annoying part is that TestNG picks up far more classes then jUnit... The tests are auto-compiled from jnario specs (jnario.org) which shouldn't make a difference - at the end it's classes compiled from java source files. Regards, Andreas mvn -Dtest=JnSpec* test ... [INFO] --- maven-surefire-plugin:2.15:test (default-test) @ a42-order-be --- [INFO] Surefire report directory: /path/target/surefire-reports [INFO] Using configured provider org.apache.maven.surefire.junitcore.JUnitCoreProvider [INFO] Using configured provider org.apache.maven.surefire.testng.TestNGProvider [INFO] parallel='none', perCoreThreadCount=true, threadCount=2, useUnlimitedThreads=false --- T E S T S --- --- T E S T S --- Running package.JnSpecBPMNProcessSpec Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.199 sec - in package.JnSpecBPMNProcessSpec Running package.JnSpecCreateTheResultMessageOfACancellationSpec Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.485 sec - in package.JnSpecCreateTheResultMessageOfACancellationSpec Running package.JnSpecServicesToSupportCancellationOfItemsOfOneOrderSpec Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.471 sec - in package.JnSpecServicesToSupportCancellationOfItemsOfOneOrderSpec Running package.JnSpecServicesToSupportCancellationOfItemsOfOnePurchaseOrderSpec Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.975 sec - in package.JnSpecServicesToSupportCancellationOfItemsOfOnePurchaseOrderSpec Running package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.262 sec - in package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec Running package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.215 sec - in package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec Running package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.225 sec - in package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec Running package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028 sec - in package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec Results : Tests run: 14, Failures: 0, Errors: 0, Skipped: 0 --- T E S T S --- --- T E S T S --- Running package.JnSpecBPMNProcessSpec$1 Configuring TestNG with: TestNG652Configurator Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.595 sec - in package.JnSpecBPMNProcessSpec$1 Running package.JnSpecBPMNProcessSpec Configuring TestNG with: TestNG652Configurator Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.693 sec - in package.JnSpecBPMNProcessSpec Running package.JnSpecCreateTheResultMessageOfACancellationSpec$1 Configuring TestNG with: TestNG652Configurator Tests run: 0, Failures: 0, Errors: 0, Skipped: 0,
webstart application and Java7u25
Hello, In Java 7u25 the following change has been introduced: http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/no_redeploy.html This requires that all the jars included in my webstart application have 2 extra entries in their manifest files. I build and I sign the jars contained in my webstart application using the Webstart Maven Plugin version 1.0-beta-3. To solve this I should add the 2 new manifest entries in all the jars used by my application, but this is not always possible, as most of my dependencies are already deployed in our Nexus repository and some of them are thirdparty dependencies, coming from external repositories. Is there a way to add those entries in all my dependencies before they are signed? Thanks! David
Preventing Maven from downloading certain versions from external repositories
Hi, In a current project, by convention, we use 1.0-LOCAL-SNAPSHOT as the default version for local builds, producing official builds only through our CI server. This works well but during local builds, Maven will needlessly look for these versions in external repositories, slowing the build down. Is there a way to configure Maven never to look for specific versions outside the local .m2 cache to avoid this slowdown? Regards, Kristian
Re: Preventing Maven from downloading certain versions from external repositories
Sure. Build in offline mode: mvn install -o It may not work everytime, but maven will complain loud enough, if it can't find an artifact in your local repo. Andreas 2013/7/25 Kristian Freed kristian.fr...@gmail.com Hi, In a current project, by convention, we use 1.0-LOCAL-SNAPSHOT as the default version for local builds, producing official builds only through our CI server. This works well but during local builds, Maven will needlessly look for these versions in external repositories, slowing the build down. Is there a way to configure Maven never to look for specific versions outside the local .m2 cache to avoid this slowdown? Regards, Kristian -- Andreas Dolk Zurmainerstraße 33 D-54292 Trier Phone「+49 651 4362884」 Mobile「+49 177 4970815」 EMail「andreas.dolk.mo...@googlemail.com」
[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 us your thoughts. The topic is essentially: Do you want the members of the Maven PMC to be social leaders of the Maven community, who's actions demonstrate the best community behaviour? The alternative is that members of the Maven PMC are here purely to complete the legal requirements that an Apache TLP has delegated to PMCs This is not black and white... The answer can be grey... And everyone is human so can make mistakes... So community, what are you expecting? - Stephen Connolly On Thursday, 25 July 2013, wrote: Author: jdcasey Date: Wed Jul 24 23:21:58 2013 New Revision: 1506778 URL: http://svn.apache.org/r1506778 Log: Adding section on PMC standards of community commitment Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1506778r1=1506777r2=1506778view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24 23:21:58 2013 @@ -176,6 +176,29 @@ The Project Management Committee has the * Voting on release artifacts. * !-- TODO: get the rest of these -- + Standards for Community Commitment + +In the spirit of supporting the health of our community, Project +Management Committee members refrain from actions that subvert the +functioning of the committee itself. + +First, Project Management Committee members should not maintain long-running +forks of Maven code outside of the project itself. Making significant +changes to Maven code outside of the project displays a lack of +investment in the community. Additionally, attempting to re-integrate +a large number of code changes in bulk overwhelms the ability of +volunteers in the community to review (and potentially veto) the +changes. This effectively thwarts the policing function of the +PMC. + +Second, Project Management Committee members should not divert +work on redesigning, reimplementing, or improving Maven code to +alternative projects outside of this community for the purposes of +reintroducing them as replacement for existing Maven code. While there +is a danger here of falling into a Not Invented Here mentality, new projects +created by Maven PMC members strictly to replace Maven code should not be +allowed. + ### [Project Management Chair]( http://www.apache.org/foundation/how-it-works.html#pmc-chair) For various legal reasons, there are certain things that the Apache -- Sent from my phone
Re: Preventing Maven from downloading certain versions from external repositories
Unfortunately we also have other internal libraries on SNAPSHOT versions that do need to be retrieved from the repository, so going offline completely is not an option. Kristian On Thu, Jul 25, 2013 at 2:12 PM, Andreas Dolk andreas.dolk.mo...@googlemail.com wrote: Sure. Build in offline mode: mvn install -o It may not work everytime, but maven will complain loud enough, if it can't find an artifact in your local repo. Andreas 2013/7/25 Kristian Freed kristian.fr...@gmail.com Hi, In a current project, by convention, we use 1.0-LOCAL-SNAPSHOT as the default version for local builds, producing official builds only through our CI server. This works well but during local builds, Maven will needlessly look for these versions in external repositories, slowing the build down. Is there a way to configure Maven never to look for specific versions outside the local .m2 cache to avoid this slowdown? Regards, Kristian -- Andreas Dolk Zurmainerstraße 33 D-54292 Trier Phone「+49 651 4362884」 Mobile「+49 177 4970815」 EMail「andreas.dolk.mo...@googlemail.com」
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)
That whole section I find pretty bizarre. - Apache is about (open-source) software. - Writing code is *good*. - Forks are *good* * * I'm put in mind of Linus' talk about why git distribution is so important - that 'if you don't think I'm doing a good job, then you can just take your code from another maintainer. *That's* what keeps a project honest and responsive to the users. I would have thought that the kinds of people who are interested in writing maven-esque code would be some of the people you'd want on a PMC. If they have a long running fork or a reimplementation, surely they would be lobbying for its integration? Merging is also good. If, despite this, they're choosing to do this elsewhere, and/or are having trouble merging projects in, isn't that a pretty sad indictment for the health of the project? Isn't it a bit like saying boo-hoo, those that are doing the actual work might go work in their own sandpit if we won't play ball, let's ex-communicate them ? Unless (as some have suspected for a while) Apache isn't about software anymore, it's about the continued existence of Apache (cfex: OpenOffice).- a political edifice where projects go to die. That's certainly what those added paragraphs say to me. On Thu, Jul 25, 2013 at 2:16 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: 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 us your thoughts. The topic is essentially: Do you want the members of the Maven PMC to be social leaders of the Maven community, who's actions demonstrate the best community behaviour? The alternative is that members of the Maven PMC are here purely to complete the legal requirements that an Apache TLP has delegated to PMCs This is not black and white... The answer can be grey... And everyone is human so can make mistakes... So community, what are you expecting? - Stephen Connolly On Thursday, 25 July 2013, wrote: Author: jdcasey Date: Wed Jul 24 23:21:58 2013 New Revision: 1506778 URL: http://svn.apache.org/r1506778 Log: Adding section on PMC standards of community commitment Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1506778r1=1506777r2=1506778view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24 23:21:58 2013 @@ -176,6 +176,29 @@ The Project Management Committee has the * Voting on release artifacts. * !-- TODO: get the rest of these -- + Standards for Community Commitment + +In the spirit of supporting the health of our community, Project +Management Committee members refrain from actions that subvert the +functioning of the committee itself. + +First, Project Management Committee members should not maintain long-running +forks of Maven code outside of the project itself. Making significant +changes to Maven code outside of the project displays a lack of +investment in the community. Additionally, attempting to re-integrate +a large number of code changes in bulk overwhelms the ability of +volunteers in the community to review (and potentially veto) the +changes. This effectively thwarts the policing function of the +PMC. + +Second, Project Management Committee members should not divert +work on redesigning, reimplementing, or improving Maven code to +alternative projects outside of this community for the purposes of +reintroducing them as replacement for existing Maven code. While there +is a danger here of falling into a Not Invented Here mentality, new projects +created by Maven PMC members strictly to replace Maven code should not be +allowed. + ### [Project Management Chair]( http://www.apache.org/foundation/how-it-works.html#pmc-chair) For various legal reasons, there are certain things that the Apache -- Sent from my phone
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)
There is clearly an underlying issue that prompts this question. My understanding is that members of the PMC are selected by other members of the PMC. There is no democratic will of the people involved. I am not sure how people get kicked off the PMC. What are the official grounds for asking someone to leave? Is there a minimum level of activity? An annual re-election of the PMC? What is the origin of the Standards for Community Commitment? They seem to contain some common sense statements about not trying to overwhelm the other committee members but that is a judgment question and clearly the PMC can take as long as required to review proposed changes and the committer who tries to move faster than the rest of the PMC can travel, will eventually have to wait for the rest to catch up. The question of not allowing forking is a bit harder to justify since it is open source and anyone is allowed to try to fork the system. The question about whether one can continue to contribute to the PMC while working on a fork is interesting. I can see where someone who has a lot of new ideas that they want to try might want to work on a major change that could be later refused for inclusion in the original project This could lead to a competitive project coming to light. How this would be treated by Apache is beyond this discussion. I suppose that if the new project was deemed to be better than the original Maven for some people, there would be some users who would shift to the new product. If everyone felt that way, we would all move and the original Maven would be dead. That is not a bad thing if the Maven PMC made a mistake in the roadmap and did not adopt the new project's enhancements when they should have. It would not be the first development tool to die a slow death as the world moved on. I can see situations arising where a fork that supports a different set of Best Practices might be the only way to satisfy some users. We have had some interesting discussions about the Maven Way that left the odd person unconvinced. Perhaps they might like to use a fork of Maven that had a different Way and supported a different set of Best Practices Would the PMC member who initiated the new project want to stay on the Maven PMC? I would expect that their level of involvement would drop as they focused on the new fork and its team. At what point can they be asked to leave if they don't want to? As a general piece of free advice, I would tread lightly in the area of purity of the roadmap and try to keep a consensus. If someone feels strongly that the roadmap is not correct, they should be free to try to fork a better way forward. The rest of the committee should continue to develop while watching the fork to see if there is a way to combine the versions and if not, see how the two paths can be supported in a way that makes sense for the user community. The person doing the fork should either resign if they see no value in their participation and see no ongoing value of the Maven development products as part of their fork or they should continue to work with the committee to keep the level of diversion as low as possible and leverage the Maven core in the fork. Ron On 25/07/2013 9:16 AM, Stephen Connolly wrote: 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 us your thoughts. The topic is essentially: Do you want the members of the Maven PMC to be social leaders of the Maven community, who's actions demonstrate the best community behaviour? The alternative is that members of the Maven PMC are here purely to complete the legal requirements that an Apache TLP has delegated to PMCs This is not black and white... The answer can be grey... And everyone is human so can make mistakes... So community, what are you expecting? - Stephen Connolly On Thursday, 25 July 2013, wrote: Author: jdcasey Date: Wed Jul 24 23:21:58 2013 New Revision: 1506778 URL: http://svn.apache.org/r1506778 Log: Adding section on PMC standards of community commitment Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1506778r1=1506777r2=1506778view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24 23:21:58 2013 @@ -176,6 +176,29 @@ The Project Management Committee has the * Voting on release artifacts. * !-- TODO: get the rest of these -- + Standards for Community Commitment + +In the spirit of supporting the health of our community, Project +Management Committee members refrain
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)
Hi Stephen and everyone, I largely agree with Nigel, and would add that in general, bureaucratic rules prohibiting various (often technically and/or socially sound) actions such as forking are a great way to ensure that skilled people distance themselves from the organization (i.e., quit the PMC, decline to join, etc.). You will be left with only bureaucrats who can tolerate those restrictions, and worse, create even more of them. Of course, there should be good, publicly stated reasons for long-running forks. Merging to mainline is ideal but not always practical in the real world. Developers need the freedom to experiment, even (perhaps especially) when in active community positions such as the PMC. That said, it is certainly the responsibility of those on the PMC to act as community leaders via best practices. But enforcing that in writing, at least as the current proposal does, seems very counterproductive to me. Regards, Curtis On Jul 25, 2013 8:59 AM, Nigel Magnay nigel.mag...@gmail.com wrote: That whole section I find pretty bizarre. - Apache is about (open-source) software. - Writing code is *good*. - Forks are *good* * * I'm put in mind of Linus' talk about why git distribution is so important - that 'if you don't think I'm doing a good job, then you can just take your code from another maintainer. *That's* what keeps a project honest and responsive to the users. I would have thought that the kinds of people who are interested in writing maven-esque code would be some of the people you'd want on a PMC. If they have a long running fork or a reimplementation, surely they would be lobbying for its integration? Merging is also good. If, despite this, they're choosing to do this elsewhere, and/or are having trouble merging projects in, isn't that a pretty sad indictment for the health of the project? Isn't it a bit like saying boo-hoo, those that are doing the actual work might go work in their own sandpit if we won't play ball, let's ex-communicate them ? Unless (as some have suspected for a while) Apache isn't about software anymore, it's about the continued existence of Apache (cfex: OpenOffice).- a political edifice where projects go to die. That's certainly what those added paragraphs say to me. On Thu, Jul 25, 2013 at 2:16 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: 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 us your thoughts. The topic is essentially: Do you want the members of the Maven PMC to be social leaders of the Maven community, who's actions demonstrate the best community behaviour? The alternative is that members of the Maven PMC are here purely to complete the legal requirements that an Apache TLP has delegated to PMCs This is not black and white... The answer can be grey... And everyone is human so can make mistakes... So community, what are you expecting? - Stephen Connolly On Thursday, 25 July 2013, wrote: Author: jdcasey Date: Wed Jul 24 23:21:58 2013 New Revision: 1506778 URL: http://svn.apache.org/r1506778 Log: Adding section on PMC standards of community commitment Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1506778r1=1506777r2=1506778view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24 23:21:58 2013 @@ -176,6 +176,29 @@ The Project Management Committee has the * Voting on release artifacts. * !-- TODO: get the rest of these -- + Standards for Community Commitment + +In the spirit of supporting the health of our community, Project +Management Committee members refrain from actions that subvert the +functioning of the committee itself. + +First, Project Management Committee members should not maintain long-running +forks of Maven code outside of the project itself. Making significant +changes to Maven code outside of the project displays a lack of +investment in the community. Additionally, attempting to re-integrate +a large number of code changes in bulk overwhelms the ability of +volunteers in the community to review (and potentially veto) the +changes. This effectively thwarts the policing function of the +PMC. + +Second, Project Management Committee members should not divert +work on redesigning, reimplementing, or improving Maven code to +alternative projects outside of this community for the purposes of
Re: Preventing Maven from downloading certain versions from external repositories
Maven has a fair number of conventions that are respected by a lot of its code. Trying to work against those conventions is likely to cause problems for you. Maybe if you explain what your goal is, we can suggest a more Maven-like way of accomplishing the same thing. On Jul 25, 2013, at 8:58 AM, Kristian Freed kristian.fr...@gmail.com wrote: Hi, In a current project, by convention, we use 1.0-LOCAL-SNAPSHOT as the default version for local builds, producing official builds only through our CI server. This works well but during local builds, Maven will needlessly look for these versions in external repositories, slowing the build down. Is there a way to configure Maven never to look for specific versions outside the local .m2 cache to avoid this slowdown? Regards, Kristian - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html!
AW: [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)
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 us your thoughts. The topic is essentially: Do you want the members of the Maven PMC to be social leaders of the Maven community, who's actions demonstrate the best community behaviour? The alternative is that members of the Maven PMC are here purely to complete the legal requirements that an Apache TLP has delegated to PMCs This is not black and white... The answer can be grey... And everyone is human so can make mistakes... So community, what are you expecting? - Stephen Connolly On Thursday, 25 July 2013, wrote: Author: jdcasey Date: Wed Jul 24 23:21:58 2013 New Revision: 1506778 URL: http://svn.apache.org/r1506778 Log: Adding section on PMC standards of community commitment Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project -roles.md?rev=1506778r1=1506777r2=1506778view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24 23:21:58 2013 @@ -176,6 +176,29 @@ The Project Management Committee has the * Voting on release artifacts. * !-- TODO: get the rest of these -- + Standards for Community Commitment + +In the spirit of supporting the health of our community, Project +Management Committee members refrain from actions that subvert the +functioning of the committee itself. + +First, Project Management Committee members should not maintain long-running +forks of Maven code outside of the project itself. Making significant +changes to Maven code outside of the project displays a lack of +investment in the community. Additionally, attempting to re-integrate +a large number of code changes in bulk overwhelms the ability of +volunteers in the community to review (and potentially veto) the +changes. This effectively thwarts the policing function of the PMC. + +Second, Project Management Committee members should not divert work +on redesigning, reimplementing, or improving Maven code to +alternative projects outside of this community for the purposes of +reintroducing them as replacement for existing Maven code. While +there is a danger here of falling into a Not Invented Here mentality, +new projects +created by Maven PMC members strictly to replace Maven code should +not be allowed. + ### [Project Management Chair]( http://www.apache.org/foundation/how-it-works.html#pmc-chair) For various legal reasons, there are certain things that the Apache -- Sent from my phone - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
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 Thursday, 25 July 2013, Curtis Rueden wrote: Hi Stephen and everyone, I largely agree with Nigel, and would add that in general, bureaucratic rules prohibiting various (often technically and/or socially sound) actions such as forking are a great way to ensure that skilled people distance themselves from the organization (i.e., quit the PMC, decline to join, etc.). You will be left with only bureaucrats who can tolerate those restrictions, and worse, create even more of them. Of course, there should be good, publicly stated reasons for long-running forks. I will not speak for the author of the proposed revision, but my understanding of the intent is that these forks should be hosted on ASF hardware in public and as part of our community. It's not about no forking, but allowing the committers to have an ongoing view of things in the community. Any committer is free to edit the wording if they want right now... The doc is a work in progress proposal Merging to mainline is ideal but not always practical in the real world. Developers need the freedom to experiment, even (perhaps especially) when in active community positions such as the PMC. That said, it is certainly the responsibility of those on the PMC to act as community leaders via best practices. But enforcing that in writing, at least as the current proposal does, seems very counterproductive to me. Regards, Curtis On Jul 25, 2013 8:59 AM, Nigel Magnay nigel.mag...@gmail.com wrote: That whole section I find pretty bizarre. - Apache is about (open-source) software. - Writing code is *good*. - Forks are *good* * * I'm put in mind of Linus' talk about why git distribution is so important - that 'if you don't think I'm doing a good job, then you can just take your code from another maintainer. *That's* what keeps a project honest and responsive to the users. I would have thought that the kinds of people who are interested in writing maven-esque code would be some of the people you'd want on a PMC. If they have a long running fork or a reimplementation, surely they would be lobbying for its integration? Merging is also good. If, despite this, they're choosing to do this elsewhere, and/or are having trouble merging projects in, isn't that a pretty sad indictment for the health of the project? Isn't it a bit like saying boo-hoo, those that are doing the actual work might go work in their own sandpit if we won't play ball, let's ex-communicate them ? Unless (as some have suspected for a while) Apache isn't about software anymore, it's about the continued existence of Apache (cfex: OpenOffice).- a political edifice where projects go to die. That's certainly what those added paragraphs say to me. On Thu, Jul 25, 2013 at 2:16 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: 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 us your thoughts. The topic is essentially: Do you want the members of the Maven PMC to be social leaders of the Maven community, who's actions demonstrate the best community behaviour? The alternative is that members of the Maven PMC are here purely to complete the legal requirements that an Apache TLP has delegated to PMCs This is not black and white... The answer can be grey... And everyone is human so can make mistakes... So community, what are you expecting? - Stephen Connolly On Thursday, 25 July 2013, wrote: Author: jdcasey Date: Wed Jul 24 23:21:58 2013 New Revision: 1506778 URL: http://svn.apache.org/r1506778 Log: Adding section on PMC standards of community commitment Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1506778r1=1506777r2=1506778view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24 23:21:58 2013 @@ -176,6 +176,29 @@ The Project Management Committee has the * Voting on release artifacts. * !-- TODO: get the rest of these -- + Standards for Community Commitment + -- Sent from my phone
Re: Preventing Maven from downloading certain versions from external repositories
Are you at least proxying the external Maven repos through your own repo. That will speed things up. Ron On 25/07/2013 9:58 AM, Kristian Freed wrote: Unfortunately we also have other internal libraries on SNAPSHOT versions that do need to be retrieved from the repository, so going offline completely is not an option. Kristian On Thu, Jul 25, 2013 at 2:12 PM, Andreas Dolk andreas.dolk.mo...@googlemail.com wrote: Sure. Build in offline mode: mvn install -o It may not work everytime, but maven will complain loud enough, if it can't find an artifact in your local repo. Andreas 2013/7/25 Kristian Freed kristian.fr...@gmail.com Hi, In a current project, by convention, we use 1.0-LOCAL-SNAPSHOT as the default version for local builds, producing official builds only through our CI server. This works well but during local builds, Maven will needlessly look for these versions in external repositories, slowing the build down. Is there a way to configure Maven never to look for specific versions outside the local .m2 cache to avoid this slowdown? Regards, Kristian -- Andreas Dolk Zurmainerstraße 33 D-54292 Trier Phone「+49 651 4362884」 Mobile「+49 177 4970815」 EMail「andreas.dolk.mo...@googlemail.com」 -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
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)
I think I'm with Ron Wheeler here. I'd add though: are you a “Project Manager” if you don't contribute to the project the changes you're doing in a fork? My gut feeling would be “no”, but that'd be ignoring the amount of contributions to the project itself (I know who you're talking about, but I have no idea what his implication in Maven proper is). Also, AFAICT, the long running fork (at least 2 years) is not open source (parts of it are, not everything) so it's hard to know what will come out of it and when, and how much implication the PMC member has in each project. Also, the fork website says there's no intent in forking Maven (but rather build upon it). Or am I wrong about what's and who's being pointed at under cover? I can hardly comment more than that, being ignorant of what happens on the Maven Dev list. If the PMC member being pointed at here is who I think he is, then I have no other problem with his work than not being open source (and apparently not a proprietary non-free product either), and creating dissension in the PMC. That being said, the more I use Maven, the more I think it's “broken by design”, and there's unfortunately nothing better out there with a big-enough community to compete. http://blog.ltgt.net/in-quest-of-the-ultimate-build-tool I wouldn't really mind if Maven collapsed like others here “predict”, I'd just switch to another contender (Gradle probably) that's just different more than being better. So in the end, don't give too much weight to my opinion here ;-) On Thu, Jul 25, 2013 at 3:16 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: 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 us your thoughts. The topic is essentially: Do you want the members of the Maven PMC to be social leaders of the Maven community, who's actions demonstrate the best community behaviour? The alternative is that members of the Maven PMC are here purely to complete the legal requirements that an Apache TLP has delegated to PMCs This is not black and white... The answer can be grey... And everyone is human so can make mistakes... So community, what are you expecting? - Stephen Connolly On Thursday, 25 July 2013, wrote: Author: jdcasey Date: Wed Jul 24 23:21:58 2013 New Revision: 1506778 URL: http://svn.apache.org/r1506778 Log: Adding section on PMC standards of community commitment Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1506778r1=1506777r2=1506778view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24 23:21:58 2013 @@ -176,6 +176,29 @@ The Project Management Committee has the * Voting on release artifacts. * !-- TODO: get the rest of these -- + Standards for Community Commitment + +In the spirit of supporting the health of our community, Project +Management Committee members refrain from actions that subvert the +functioning of the committee itself. + +First, Project Management Committee members should not maintain long-running +forks of Maven code outside of the project itself. Making significant +changes to Maven code outside of the project displays a lack of +investment in the community. Additionally, attempting to re-integrate +a large number of code changes in bulk overwhelms the ability of +volunteers in the community to review (and potentially veto) the +changes. This effectively thwarts the policing function of the +PMC. + +Second, Project Management Committee members should not divert +work on redesigning, reimplementing, or improving Maven code to +alternative projects outside of this community for the purposes of +reintroducing them as replacement for existing Maven code. While there +is a danger here of falling into a Not Invented Here mentality, new projects +created by Maven PMC members strictly to replace Maven code should not be +allowed. + ### [Project Management Chair]( http://www.apache.org/foundation/how-it-works.html#pmc-chair) For various legal reasons, there are certain things that the Apache -- Sent from my phone -- Thomas Broyer /tɔ.ma.bʁwa.je/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
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)
So what's outlined in those paragraphs have counter examples at the ASF. I do not believe it is a bad thing to have alternative distributions or forks, and it doesn't matter where they are. What you are saying is that committers are obliged to share all their work with other committers. Which is more coercion than a matter of choice. For all work that happens within the bounds of the ASF absolutely. Core changes should not be made projects without discussion. That's a good rule and helps with stability. For work that happens outside the bounds of the ASF an author is obliged to do nothing of the sort and the assert as much is absurd quite honestly. What right does the ASF have over work that is not done at Apache? In fact there are people on the ASF Board who belong to companies that have long standing forks and/or alternative distributions of ASF projects. Look at Hadoop: there are two companies that have people on PMCs who maintain alternative distributions with code that does not exist in standard distributions. Both Cloudera and HortonWorks maintain versions of Hadoop that are not compatible and/or have different code than the version from Apache. There is selective patching and additions made to try and provide a better distribution of Hadoop. I don't think this is a bad thing. This also happens with Cassandra and the people who work at Datastax where an alternative distribution is made. I don't know as much about what is in those distributions insofar as code that doesn't exist in the standard Apache distribution. Again, I don't think this is a bad thing. I'm sure they would all tell you that they are trying to make a better version of said project, they work with customers, work at a different pace and hope to integrate their work back in later if possible. If this is a sideways attempt to address what I'm doing in Tesla, which is what it appears like to me, then just start a discussion on the dev list. Happy to discuss it. But if someone posits that all work related to an Apache project has to be done at Apache, then I will say that is a ridiculous supposition and you can find ten counter examples in ten minutes if you went looking. On Jul 25, 2013, at 10:31 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Thursday, 25 July 2013, Curtis Rueden wrote: Hi Stephen and everyone, I largely agree with Nigel, and would add that in general, bureaucratic rules prohibiting various (often technically and/or socially sound) actions such as forking are a great way to ensure that skilled people distance themselves from the organization (i.e., quit the PMC, decline to join, etc.). You will be left with only bureaucrats who can tolerate those restrictions, and worse, create even more of them. Of course, there should be good, publicly stated reasons for long-running forks. I will not speak for the author of the proposed revision, but my understanding of the intent is that these forks should be hosted on ASF hardware in public and as part of our community. It's not about no forking, but allowing the committers to have an ongoing view of things in the community. Any committer is free to edit the wording if they want right now... The doc is a work in progress proposal Merging to mainline is ideal but not always practical in the real world. Developers need the freedom to experiment, even (perhaps especially) when in active community positions such as the PMC. That said, it is certainly the responsibility of those on the PMC to act as community leaders via best practices. But enforcing that in writing, at least as the current proposal does, seems very counterproductive to me. Regards, Curtis On Jul 25, 2013 8:59 AM, Nigel Magnay nigel.mag...@gmail.com wrote: That whole section I find pretty bizarre. - Apache is about (open-source) software. - Writing code is *good*. - Forks are *good* * * I'm put in mind of Linus' talk about why git distribution is so important - that 'if you don't think I'm doing a good job, then you can just take your code from another maintainer. *That's* what keeps a project honest and responsive to the users. I would have thought that the kinds of people who are interested in writing maven-esque code would be some of the people you'd want on a PMC. If they have a long running fork or a reimplementation, surely they would be lobbying for its integration? Merging is also good. If, despite this, they're choosing to do this elsewhere, and/or are having trouble merging projects in, isn't that a pretty sad indictment for the health of the project? Isn't it a bit like saying boo-hoo, those that are doing the actual work might go work in their own sandpit if we won't play ball, let's ex-communicate them ? Unless (as some have suspected for a while) Apache isn't about software anymore, it's about the continued existence of Apache (cfex: OpenOffice).- a political edifice where
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)
The section that was added below has nothing to do with the rest of the document. It should be reverted, as it is basically nonsense as Jason has just pointed out. Maven has lots of other problems. This really doesn't seem like one anyone should be spending any time or energy on. Stephen On 25 July 2013 14:16, Stephen Connolly stephen.alan.conno...@gmail.com wrote: 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 us your thoughts. The topic is essentially: Do you want the members of the Maven PMC to be social leaders of the Maven community, who's actions demonstrate the best community behaviour? The alternative is that members of the Maven PMC are here purely to complete the legal requirements that an Apache TLP has delegated to PMCs This is not black and white... The answer can be grey... And everyone is human so can make mistakes... So community, what are you expecting? - Stephen Connolly On Thursday, 25 July 2013, wrote: Author: jdcasey Date: Wed Jul 24 23:21:58 2013 New Revision: 1506778 URL: http://svn.apache.org/r1506778 Log: Adding section on PMC standards of community commitment Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1506778r1=1506777r2=1506778view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24 23:21:58 2013 @@ -176,6 +176,29 @@ The Project Management Committee has the * Voting on release artifacts. * !-- TODO: get the rest of these -- + Standards for Community Commitment + +In the spirit of supporting the health of our community, Project +Management Committee members refrain from actions that subvert the +functioning of the committee itself. + +First, Project Management Committee members should not maintain long-running +forks of Maven code outside of the project itself. Making significant +changes to Maven code outside of the project displays a lack of +investment in the community. Additionally, attempting to re-integrate +a large number of code changes in bulk overwhelms the ability of +volunteers in the community to review (and potentially veto) the +changes. This effectively thwarts the policing function of the +PMC. + +Second, Project Management Committee members should not divert +work on redesigning, reimplementing, or improving Maven code to +alternative projects outside of this community for the purposes of +reintroducing them as replacement for existing Maven code. While there +is a danger here of falling into a Not Invented Here mentality, new projects +created by Maven PMC members strictly to replace Maven code should not be +allowed. + ### [Project Management Chair]( http://www.apache.org/foundation/how-it-works.html#pmc-chair) For various legal reasons, there are certain things that the Apache -- Sent from my phone - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven plugin trademarks [Re: Downloading a file for shipping in an artifact]
Hi, For the record, the two pages above were patched. TL;DR *don't name your maven plugin maven-foo-plugin but foo-maven-plugin. Legally compulsory, not just a recommendation.* Cheers Le 12 juin 2013 14:13, Baptiste MATHUS bmat...@batmat.net a écrit : 2013/6/12 Stephen Connolly stephen.alan.conno...@gmail.com On 12 June 2013 11:04, Stephen Colebourne scolebou...@joda.org wrote: I made this mistake too. Could I make some suggestions? Add the banned naming to the top of plugin guides, such as: http://maven.apache.org/guides/plugin/guide-java-plugin-development.html +1, anyone want to take a stab at providing a patch? Change this page to only have the single prefix-maven-plugin example: http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html I scan read and thought they were just two options. +1, anyone want to take a stab at providing a patch? I'll propose that patch this week, maybe tonight if no one else does it before. -- Baptiste
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)
As part of trying to kick this project back to life, we need to grow both committers and the PMC. One of the issues with growing either is determining if potential candidates are the right sort of person. There is a disagreement in the PMC as to whether dedication to the Maven project community is relevant to such discussions. For growing committers, this is usually a small issue, if at all. For growing the PMC it can be quite contentious, especially when considering controversial candidates. In an effort to try and harmonise the PMC, I - as one of the fence sitters - started this debate... In essence calling on that group that trumps the PMC... ie the community. John posted the proposed - remember we are CTR not RTC - addition to the page I started, at least as a stalking horse (or perhaps it is his opinion... I will leave it up to him to state his position) On Thursday, 25 July 2013, Jason van Zyl wrote: So what's outlined in those paragraphs have counter examples at the ASF. I do not believe it is a bad thing to have alternative distributions or forks, and it doesn't matter where they are. What you are saying is that committers are obliged to share all their work with other committers. Which is more coercion than a matter of choice. For all work that happens within the bounds of the ASF absolutely. Core changes should not be made projects without discussion. That's a good rule and helps with stability. For work that happens outside the bounds of the ASF an author is obliged to do nothing of the sort and the assert as much is absurd quite honestly. What right does the ASF have over work that is not done at Apache? In fact there are people on the ASF Board who belong to companies that have long standing forks and/or alternative distributions of ASF projects. Look at Hadoop: there are two companies that have people on PMCs who maintain alternative distributions with code that does not exist in standard distributions. Both Cloudera and HortonWorks maintain versions of Hadoop that are not compatible and/or have different code than the version from Apache. There is selective patching and additions made to try and provide a better distribution of Hadoop. I don't think this is a bad thing. This also happens with Cassandra and the people who work at Datastax where an alternative distribution is made. I don't know as much about what is in those distributions insofar as code that doesn't exist in the standard Apache distribution. Again, I don't think this is a bad thing. I'm sure they would all tell you that they are trying to make a better version of said project, they work with customers, work at a different pace and hope to integrate their work back in later if possible. If this is a sideways attempt to address what I'm doing in Tesla, which is what it appears like to me, then just start a discussion on the dev list. Happy to discuss it. It would be great if you could have that discussion on the dev list any way... But what prompted me to prod John to commit the text and me to start this discussion is a long running debate on the PMC private list as to what kind of person should be on the PMC... By long running I mean that some aspects of this are more than a year old and have been in mails since before you started to re-engage with the project. That does not mean that the stuff you are doing at Tesla is not relevant or a trigger for trying to sort out the disconnect between two camps in the PMC... More that it is being considered in a common context of an ongoing debate, and in an effort to resolve the debate we are asking those we are supposed to serve for their input. HTH But if someone posits that all work related to an Apache project has to be done at Apache, then I will say that is a ridiculous supposition and you can find ten counter examples in ten minutes if you went looking. On Jul 25, 2013, at 10:31 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Thursday, 25 July 2013, Curtis Rueden wrote: Hi Stephen and everyone, I largely agree with Nigel, and would add that in general, bureaucratic rules prohibiting various (often technically and/or socially sound) actions such as forking are a great way to ensure that skilled people distance themselves from the organization (i.e., quit the PMC, decline to join, etc.). You will be left with only bureaucrats who can tolerate those restrictions, and worse, create even more of them. Of course, there should be good, publicly stated reasons for long-running forks. I will not speak for the author of the proposed revision, but my understanding of the intent is that these forks should be hosted on ASF hardware in public and as part of our community. It's not about no forking, but allowing the committers to have an ongoing view of things in the community. Any committer is free to edit the wording if they want right now... The doc is a work in progress
Re: Preventing Maven from downloading certain versions from external repositories
Hi Kristian, In a current project, by convention, we use 1.0-LOCAL-SNAPSHOT as the default version for local builds, producing official builds only through our CI server. This works well but during local builds, Maven will needlessly look for these versions in external repositories, slowing the build down. If the LOCAL-SNAPSHOT modules are all part of the same reactor, Maven shouldn't try to resolve them remotely. So I am assuming you have multiple codebases with inter-codebase dependencies? In that case, you could create another multi-module POM at the very top level, putting each codebase in a subdirectory, then build all projects as part of the same reactor. The LOCAL-SNAPSHOT dependency couplings should all get resolved from the reactor then. Regards, Curtis On Thu, Jul 25, 2013 at 8:58 AM, Kristian Freed kristian.fr...@gmail.comwrote: Unfortunately we also have other internal libraries on SNAPSHOT versions that do need to be retrieved from the repository, so going offline completely is not an option. Kristian On Thu, Jul 25, 2013 at 2:12 PM, Andreas Dolk andreas.dolk.mo...@googlemail.com wrote: Sure. Build in offline mode: mvn install -o It may not work everytime, but maven will complain loud enough, if it can't find an artifact in your local repo. Andreas 2013/7/25 Kristian Freed kristian.fr...@gmail.com Hi, In a current project, by convention, we use 1.0-LOCAL-SNAPSHOT as the default version for local builds, producing official builds only through our CI server. This works well but during local builds, Maven will needlessly look for these versions in external repositories, slowing the build down. Is there a way to configure Maven never to look for specific versions outside the local .m2 cache to avoid this slowdown? Regards, Kristian -- Andreas Dolk Zurmainerstraße 33 D-54292 Trier Phone「+49 651 4362884」 Mobile「+49 177 4970815」 EMail「andreas.dolk.mo...@googlemail.com」
Re: Preventing Maven from downloading certain versions from external repositories
Hi, I use xxx-LOCAL for this kind of thing, since they are not considered as snapshots, maven won't try everyday to download a new local version. Vincent 2013/7/25 Ron Wheeler rwhee...@artifact-software.com Are you at least proxying the external Maven repos through your own repo. That will speed things up. Ron On 25/07/2013 9:58 AM, Kristian Freed wrote: Unfortunately we also have other internal libraries on SNAPSHOT versions that do need to be retrieved from the repository, so going offline completely is not an option. Kristian On Thu, Jul 25, 2013 at 2:12 PM, Andreas Dolk andreas.dolk.mobil@googlemail.**com andreas.dolk.mo...@googlemail.com wrote: Sure. Build in offline mode: mvn install -o It may not work everytime, but maven will complain loud enough, if it can't find an artifact in your local repo. Andreas 2013/7/25 Kristian Freed kristian.fr...@gmail.com Hi, In a current project, by convention, we use 1.0-LOCAL-SNAPSHOT as the default version for local builds, producing official builds only through our CI server. This works well but during local builds, Maven will needlessly look for these versions in external repositories, slowing the build down. Is there a way to configure Maven never to look for specific versions outside the local .m2 cache to avoid this slowdown? Regards, Kristian -- Andreas Dolk Zurmainerstraße 33 D-54292 Trier Phone「+49 651 4362884」 Mobile「+49 177 4970815」 EMail「andreas.dolk.mobil@**googlemail.comandreas.dolk.mo...@googlemail.com 」 -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
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 12:03 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As part of trying to kick this project back to life, we need to grow both committers and the PMC. You don't need either. You need people who do work. People who do work may happen to be a committer or PMC member but you have it backward. You need a lot of people who do a lot of work to drive a project forward. One of the issues with growing either is determining if potential candidates are the right sort of person. People who do work. I'm not sure how you decide the right sort of person if it's not based in the actual contributions to the project. Not what might be contributed, but what has actually been contributed. There is a disagreement in the PMC as to whether dedication to the Maven project community is relevant to such discussions. Are not people who do work dedicated? Are not people who have done the most work the most dedicated? To me doing work is the whole basis of a meritocracy, doing work is table stakes for being on the PMC and is first condition at least in a meritocracy. For growing committers, this is usually a small issue, if at all. For growing the PMC it can be quite contentious, especially when considering controversial candidates. Discussions should be about the work that is being done on the project. Everything outside of that is not within the purview of the discussion. How can it be? It's generally looking at the contributions over the last 6 months or a year and making a decision based on the merit of that work. In an effort to try and harmonise the PMC, I - as one of the fence sitters - started this debate... In essence calling on that group that trumps the PMC... ie the community. John posted the proposed - remember we are CTR not RTC - addition to the page I started, at least as a stalking horse (or perhaps it is his opinion... I will leave it up to him to state his position) On Thursday, 25 July 2013, Jason van Zyl wrote: So what's outlined in those paragraphs have counter examples at the ASF. I do not believe it is a bad thing to have alternative distributions or forks, and it doesn't matter where they are. What you are saying is that committers are obliged to share all their work with other committers. Which is more coercion than a matter of choice. For all work that happens within the bounds of the ASF absolutely. Core changes should not be made projects without discussion. That's a good rule and helps with stability. For work that happens outside the bounds of the ASF an author is obliged to do nothing of the sort and the assert as much is absurd quite honestly. What right does the ASF have over work that is not done at Apache? In fact there are people on the ASF Board who belong to companies that have long standing forks and/or alternative distributions of ASF projects. Look at Hadoop: there are two companies that have people on PMCs who maintain alternative distributions with code that does not exist in standard distributions. Both Cloudera and HortonWorks maintain versions of Hadoop that are not compatible and/or have different code than the version from Apache. There is selective patching and additions made to try and provide a better distribution of Hadoop. I don't think this is a bad thing. This also happens with Cassandra and the people who work at Datastax where an alternative distribution is made. I don't know as much about what is in those distributions insofar as code that doesn't exist in the standard Apache distribution. Again, I don't think this is a bad thing. I'm sure they would all tell you that they are trying to make a better version of said project, they work with customers, work at a different pace and hope to integrate their work back in later if possible. If this is a sideways attempt to address what I'm doing in Tesla, which is what it appears like to me, then just start a discussion on the dev list. Happy to discuss it. It would be great if you could have that discussion on the dev list any way... But what prompted me to prod John to commit the text and me to start this discussion is a long running debate on the PMC private list as to what kind of person should be on the PMC... By long running I mean that some aspects of this are more than a year old and have been in mails since before you started to re-engage with the project. That does not mean that the stuff you are doing at Tesla is not relevant or a trigger for trying to sort out the disconnect between two camps in the PMC... More that it is being considered in a common context of an ongoing debate, and in an effort to resolve the debate we are asking those we are supposed to serve for their input. HTH But if someone posits that all work related to an Apache project has to be done at Apache, then I will say that is a ridiculous supposition and you can find ten counter examples in ten minutes if
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)
+1 The candidates should be people who contribute in terms of code/patch. -Original Message- From: Jason van Zyl [mailto:ja...@tesla.io] Sent: Thursday, July 25, 2013 9:56 AM To: Maven Users List Subject: 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 12:03 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As part of trying to kick this project back to life, we need to grow both committers and the PMC. You don't need either. You need people who do work. People who do work may happen to be a committer or PMC member but you have it backward. You need a lot of people who do a lot of work to drive a project forward. One of the issues with growing either is determining if potential candidates are the right sort of person. People who do work. I'm not sure how you decide the right sort of person if it's not based in the actual contributions to the project. Not what might be contributed, but what has actually been contributed. There is a disagreement in the PMC as to whether dedication to the Maven project community is relevant to such discussions. Are not people who do work dedicated? Are not people who have done the most work the most dedicated? To me doing work is the whole basis of a meritocracy, doing work is table stakes for being on the PMC and is first condition at least in a meritocracy. For growing committers, this is usually a small issue, if at all. For growing the PMC it can be quite contentious, especially when considering controversial candidates. Discussions should be about the work that is being done on the project. Everything outside of that is not within the purview of the discussion. How can it be? It's generally looking at the contributions over the last 6 months or a year and making a decision based on the merit of that work. In an effort to try and harmonise the PMC, I - as one of the fence sitters - started this debate... In essence calling on that group that trumps the PMC... ie the community. John posted the proposed - remember we are CTR not RTC - addition to the page I started, at least as a stalking horse (or perhaps it is his opinion... I will leave it up to him to state his position) On Thursday, 25 July 2013, Jason van Zyl wrote: So what's outlined in those paragraphs have counter examples at the ASF. I do not believe it is a bad thing to have alternative distributions or forks, and it doesn't matter where they are. What you are saying is that committers are obliged to share all their work with other committers. Which is more coercion than a matter of choice. For all work that happens within the bounds of the ASF absolutely. Core changes should not be made projects without discussion. That's a good rule and helps with stability. For work that happens outside the bounds of the ASF an author is obliged to do nothing of the sort and the assert as much is absurd quite honestly. What right does the ASF have over work that is not done at Apache? In fact there are people on the ASF Board who belong to companies that have long standing forks and/or alternative distributions of ASF projects. Look at Hadoop: there are two companies that have people on PMCs who maintain alternative distributions with code that does not exist in standard distributions. Both Cloudera and HortonWorks maintain versions of Hadoop that are not compatible and/or have different code than the version from Apache. There is selective patching and additions made to try and provide a better distribution of Hadoop. I don't think this is a bad thing. This also happens with Cassandra and the people who work at Datastax where an alternative distribution is made. I don't know as much about what is in those distributions insofar as code that doesn't exist in the standard Apache distribution. Again, I don't think this is a bad thing. I'm sure they would all tell you that they are trying to make a better version of said project, they work with customers, work at a different pace and hope to integrate their work back in later if possible. If this is a sideways attempt to address what I'm doing in Tesla, which is what it appears like to me, then just start a discussion on the dev list. Happy to discuss it. It would be great if you could have that discussion on the dev list any way... But what prompted me to prod John to commit the text and me to start this discussion is a long running debate on the PMC private list as to what kind of person should be on the PMC... By long running I mean that some aspects of this are more than a year old and have been in mails since before you started to re-engage with the project. That does not mean that the stuff you are doing at Tesla is not relevant or a trigger for trying to sort
RE: release prepare with git doesn't finish
I would suggest using msysgit with plink and pageant for ssh authentication, worked like a charmed for me. On Jul 23, 2013 4:38 PM, Adrien Ruffié adriennolar...@hotmail.fr wrote: Same thing maven chain parameter like ssh://git:adryen31:mypassword@rd1 /myapp.git Just stupid parameters I think ... -Message d'origine- De : Francesco Mari [mailto:mari.france...@gmail.com] Envoyé : mardi 23 juillet 2013 14:02 À : Maven Users List Objet : Re: release prepare with git doesn't finish Try to use -Dusername to specify a user name, too. 2013/7/23 Adrien Ruffié adriennolar...@hotmail.fr Operation does not work very well ... C:\Java\Workspaces\Indigo\myappcrm5mvn -Darguments=-Dmaven.test.skip=true -Pdistribution-packaging release:prepare release:perform -Dtag=Spring2013 /005 -Dcom.myapp.frontline:myapp-webapp=Spring2013/005 -Dcom.myapp.frontline:myapp-install-wizard=Spring2013/005 -DreleaseVersion=Spring2013-005 -Ddev elopmentVersion=Spring2013-006-SNAPSHOT -Dpassword=mypassword -X it try to push with following url git push ssh://git:mypassword@rd1/myapp.git release/Spring2013:release/Spring2013 I think it confuses the password with the login ... therefore the url does not work -Message d'origine- De : Francesco Mari [mailto:mari.france...@gmail.com] Envoyé : mardi 23 juillet 2013 12:17 À : Maven Users List Objet : Re: release prepare with git doesn't finish Please retry the same command line with -Dpassword=... outside of -Darguments= Moreover, -Dpassphrase is not a valid argument for the goals you used. 2013/7/23 Adrien Ruffié adriennolar...@hotmail.fr No sorry I have try following command : mvn -Darguments=-Dmaven.test.skip=true -Pdistribution-packaging -Dpassword=mypassword release:prepare release:perform --batch-mode -Dtag=Spring2013/005 -Dcom.myapp.frontline:myapp-webapp=Spring2013/005 -Dcom.myapp.frontline:myapp-install-wizard=Spring2013/005 -DreleaseVersion=Spring2013-005 -DdevelopmentVersion=Spring2013-006-SNAPSHOT -Dpassword=mypassword I also try with passphrase like: mvn -Darguments=-Dmaven.test.skip=true -Pdistribution-packaging -Dpassphrase=mypassword release:prepare release:perform --batch-mode -Dtag=Spring2013/005 -Dcom.myapp.frontline:myapp-webapp=Spring2013/005 -Dcom.myapp.frontline:myapp-install-wizard=Spring2013/005 -DreleaseVersion=Spring2013-005 -DdevelopmentVersion=Spring2013-006-SNAPSHOT -Dpassphrase=mypassword but nothing was released ... also where do you put the specify the argument ? into mvn -Darguments=... or outside mvn -Darguments=... ? -Message d'origine- De : Francesco Mari [mailto:mari.france...@gmail.com] Envoyé : mardi 23 juillet 2013 11:49 À : Maven Users List Objet : Re: release prepare with git doesn't finish The release:prepare goal has a password parameter which you can use from the command line [1]. [1]: http://maven.apache.org/maven-release/maven-release-plugin/prepare-m oj o.html#password 2013/7/23 Adrien Ruffié adriennolar...@hotmail.fr Ok I have try without batch mode (on windows) and I have try to run the previous command before it block ... git push ssh://git@rd1/myapp.git release/Spring2013:release/Spring2013 and when I tried the following git line was prompt: Enter passphrase for key '/c/Users/a.ruffie/.ssh/id_rsa': After enter my passphrase the commit will be push correctly: Counting objects: 26, done. Delta compression using up to 4 threads. Compressing objects: 100% (15/15), done. Writing objects: 100% (18/18), 327.80 KiB | 0 bytes/s, done. Total 18 (delta 13), reused 4 (delta 3) To ssh://git@rd1/myapp.git 200c7f1..3f5cd17 release/Spring2013 - release/Spring2013 So I suppose the commit of git push ssh://git@rd1/myapp.git release/Spring2013:release/Spring2013 remains idle because the passphrase cannot be provided. Do you not a means to avoid this problem ? Like provide passphrase into maven command line ? like release:perform -Dgit.password=mypassword Great thank and best regards. Adrien -Message d'origine- De : Francesco Mari [mailto:mari.france...@gmail.com] Envoyé : mardi 23 juillet 2013 10:54 À : Maven Users List Objet : Re: release prepare with git doesn't finish I had a lot of issues using Git on Windows, especially combined with the Maven Release Plugin. It looks like that the issue is related to long path names. It may be that your project has long nested paths (usually Java applications have this problem). Try to move your project to a shorter path, e.g. C:\prj. This will not fix the issue, but it works sometimes. By the way, I use a Linux VM to release stuff. Working on Windows is sad, overall. 2013/7/23
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)
The Apache Foundation values Community over Code. Merit is thus not just a question about writing the best code but helping and fostering the community around that code. This in deciding committers we need people who are good enough *both* socially and technically. This can be a mix, eg one very good technical person who is poor socially can be counterweighted by a good social person who is (comparatively poor technically... But sufficiently socially aware of their technical ability) If you don't like community over code, then Apache may not be the place for you... And that's ok. But as you step up in engagement with an Apache community, you should be at least ok with the ASF values. How that impacts what it means to be on the PMC is therefore relevant. Should it be a strong step and we only take people into the PMC that repeatedly demonstrate that they value the community over code (large code dumps from long running private forks are not community friendly to a lot of people's mind... Repeatedly causing conflict within the community is another)? Or should we say the PMC is just to perform the legal duty and leave the religion to members of the ASF? That is what needs to be answered On Thursday, 25 July 2013, Sankaran, Nambi wrote: +1 The candidates should be people who contribute in terms of code/patch. -Original Message- From: Jason van Zyl [mailto:ja...@tesla.io] Sent: Thursday, July 25, 2013 9:56 AM To: Maven Users List Subject: 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 12:03 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As part of trying to kick this project back to life, we need to grow both committers and the PMC. You don't need either. You need people who do work. People who do work may happen to be a committer or PMC member but you have it backward. You need a lot of people who do a lot of work to drive a project forward. One of the issues with growing either is determining if potential candidates are the right sort of person. People who do work. I'm not sure how you decide the right sort of person if it's not based in the actual contributions to the project. Not what might be contributed, but what has actually been contributed. There is a disagreement in the PMC as to whether dedication to the Maven project community is relevant to such discussions. Are not people who do work dedicated? Are not people who have done the most work the most dedicated? To me doing work is the whole basis of a meritocracy, doing work is table stakes for being on the PMC and is first condition at least in a meritocracy. For growing committers, this is usually a small issue, if at all. For growing the PMC it can be quite contentious, especially when considering controversial candidates. Discussions should be about the work that is being done on the project. Everything outside of that is not within the purview of the discussion. How can it be? It's generally looking at the contributions over the last 6 months or a year and making a decision based on the merit of that work. In an effort to try and harmonise the PMC, I - as one of the fence sitters - started this debate... In essence calling on that group that trumps the PMC... ie the community. John posted the proposed - remember we are CTR not RTC - addition to the page I started, at least as a stalking horse (or perhaps it is his opinion... I will leave it up to him to state his position) On Thursday, 25 July 2013, Jason van Zyl wrote: So what's outlined in those paragraphs have counter examples at the ASF. I do not believe it is a bad thing to have alternative distributions or forks, and it doesn't matter where they are. What you are saying is that committers are obliged to share all their work with other committers. Which is more coercion than a matter of choice. For all work that happens within the bounds of the ASF absolutely. Core changes should not be made projects without discussion. That's a good rule and helps with stability. For work that happens outside the bounds of the ASF an author is obliged to do nothing of the sort and the assert as much is absurd quite honestly. What right does the ASF have over work that is not done at Apache? In fact there are people on the ASF Board who belong to companies that have long standing forks and/or alternative distributions of ASF projects. Look at Hadoop: there are two companies that have people on PMCs who maintain alternative distributions with code that does not exist in standard distributions. Both Cloudera and HortonWorks maintain versions of Hadoop that are not compatible and/or have different code than the version from Apache. There is selective patching and additions made to try and provide a better
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)
All what-ifs. The decisions, as I said, should be made on the typical 6-12 month period of contribution. Everything is encapsulated there: the code done, how it was introduced, how it was delivered and if there were no issues then that can be the basis to make a decision. Everything outside the bounds of that is speculation. On Jul 25, 2013, at 1:37 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: The Apache Foundation values Community over Code. Merit is thus not just a question about writing the best code but helping and fostering the community around that code. This in deciding committers we need people who are good enough *both* socially and technically. This can be a mix, eg one very good technical person who is poor socially can be counterweighted by a good social person who is (comparatively poor technically... But sufficiently socially aware of their technical ability) If you don't like community over code, then Apache may not be the place for you... And that's ok. But as you step up in engagement with an Apache community, you should be at least ok with the ASF values. How that impacts what it means to be on the PMC is therefore relevant. Should it be a strong step and we only take people into the PMC that repeatedly demonstrate that they value the community over code (large code dumps from long running private forks are not community friendly to a lot of people's mind... Repeatedly causing conflict within the community is another)? Or should we say the PMC is just to perform the legal duty and leave the religion to members of the ASF? That is what needs to be answered On Thursday, 25 July 2013, Sankaran, Nambi wrote: +1 The candidates should be people who contribute in terms of code/patch. -Original Message- From: Jason van Zyl [mailto:ja...@tesla.io] Sent: Thursday, July 25, 2013 9:56 AM To: Maven Users List Subject: 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 12:03 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As part of trying to kick this project back to life, we need to grow both committers and the PMC. You don't need either. You need people who do work. People who do work may happen to be a committer or PMC member but you have it backward. You need a lot of people who do a lot of work to drive a project forward. One of the issues with growing either is determining if potential candidates are the right sort of person. People who do work. I'm not sure how you decide the right sort of person if it's not based in the actual contributions to the project. Not what might be contributed, but what has actually been contributed. There is a disagreement in the PMC as to whether dedication to the Maven project community is relevant to such discussions. Are not people who do work dedicated? Are not people who have done the most work the most dedicated? To me doing work is the whole basis of a meritocracy, doing work is table stakes for being on the PMC and is first condition at least in a meritocracy. For growing committers, this is usually a small issue, if at all. For growing the PMC it can be quite contentious, especially when considering controversial candidates. Discussions should be about the work that is being done on the project. Everything outside of that is not within the purview of the discussion. How can it be? It's generally looking at the contributions over the last 6 months or a year and making a decision based on the merit of that work. In an effort to try and harmonise the PMC, I - as one of the fence sitters - started this debate... In essence calling on that group that trumps the PMC... ie the community. John posted the proposed - remember we are CTR not RTC - addition to the page I started, at least as a stalking horse (or perhaps it is his opinion... I will leave it up to him to state his position) On Thursday, 25 July 2013, Jason van Zyl wrote: So what's outlined in those paragraphs have counter examples at the ASF. I do not believe it is a bad thing to have alternative distributions or forks, and it doesn't matter where they are. What you are saying is that committers are obliged to share all their work with other committers. Which is more coercion than a matter of choice. For all work that happens within the bounds of the ASF absolutely. Core changes should not be made projects without discussion. That's a good rule and helps with stability. For work that happens outside the bounds of the ASF an author is obliged to do nothing of the sort and the assert as much is absurd quite honestly. What right does the ASF have over work that is not done at Apache? In fact there are people on the ASF Board who belong to companies that have long standing forks
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)
I also find it quite odd an almost offensive to the open source community in general to state that a PMC member shall not be allowed to fork too much around. It's not a marriage, you know ;-). I tend to agree with Jason: the PMC needs people who *do* stuff, meaning: * bring the project foward (with discussions like this one, or the JDK5/JDK6 threads). * keep a close eye on commits. * keep a very close eye on release votes. * continue to assure that we don't do anything that the ASFdoesn't allow, while making sure that we don't burden ourselfs with bulky processes to achieve that. It's a tough responsibility and it requires some dedication to the project. I explicitly do not think that it's the responsibility of the PMC to make sure that the maven project will never die out. That I'd find a bit unnatural and against any best-of-breed principles, which worked out quite well for open source software (and especially their users) in the past. Cheers, Andreas 2013/7/25 Sankaran, Nambi nsanka...@ebay.com +1 The candidates should be people who contribute in terms of code/patch. -Original Message- From: Jason van Zyl [mailto:ja...@tesla.io] Sent: Thursday, July 25, 2013 9:56 AM To: Maven Users List Subject: 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 12:03 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As part of trying to kick this project back to life, we need to grow both committers and the PMC. You don't need either. You need people who do work. People who do work may happen to be a committer or PMC member but you have it backward. You need a lot of people who do a lot of work to drive a project forward. One of the issues with growing either is determining if potential candidates are the right sort of person. People who do work. I'm not sure how you decide the right sort of person if it's not based in the actual contributions to the project. Not what might be contributed, but what has actually been contributed. There is a disagreement in the PMC as to whether dedication to the Maven project community is relevant to such discussions. Are not people who do work dedicated? Are not people who have done the most work the most dedicated? To me doing work is the whole basis of a meritocracy, doing work is table stakes for being on the PMC and is first condition at least in a meritocracy. For growing committers, this is usually a small issue, if at all. For growing the PMC it can be quite contentious, especially when considering controversial candidates. Discussions should be about the work that is being done on the project. Everything outside of that is not within the purview of the discussion. How can it be? It's generally looking at the contributions over the last 6 months or a year and making a decision based on the merit of that work. In an effort to try and harmonise the PMC, I - as one of the fence sitters - started this debate... In essence calling on that group that trumps the PMC... ie the community. John posted the proposed - remember we are CTR not RTC - addition to the page I started, at least as a stalking horse (or perhaps it is his opinion... I will leave it up to him to state his position) On Thursday, 25 July 2013, Jason van Zyl wrote: So what's outlined in those paragraphs have counter examples at the ASF. I do not believe it is a bad thing to have alternative distributions or forks, and it doesn't matter where they are. What you are saying is that committers are obliged to share all their work with other committers. Which is more coercion than a matter of choice. For all work that happens within the bounds of the ASF absolutely. Core changes should not be made projects without discussion. That's a good rule and helps with stability. For work that happens outside the bounds of the ASF an author is obliged to do nothing of the sort and the assert as much is absurd quite honestly. What right does the ASF have over work that is not done at Apache? In fact there are people on the ASF Board who belong to companies that have long standing forks and/or alternative distributions of ASF projects. Look at Hadoop: there are two companies that have people on PMCs who maintain alternative distributions with code that does not exist in standard distributions. Both Cloudera and HortonWorks maintain versions of Hadoop that are not compatible and/or have different code than the version from Apache. There is selective patching and additions made to try and provide a better distribution of Hadoop. I don't think this is a bad thing. This also happens with Cassandra and the people who work at Datastax where an alternative distribution is made. I don't know as much about what is in those distributions
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)
This community is created around maven, which is a software (code) written in java. Lot of people use maven (including me) on a daily basis, because of the value it provides. We use it because the code works. Some of the users, eventually become contributors and committers. Just like many opensource project, maven was initially created by one developer and now it has grown with many committers. For the project to thrive, we need a strong leader in place who can take guide others, take decisions and move the project forward. ( Jenkins is a good example ) If we have group of people with great attitude, the community will a great place for discussions, but decisions will not be made and progress will not happen. This is the reason to recruit people who can code. Btw, it is easier to teach someone who can code to talk. But, it is harder to teach someone who can talk to code. I have no desire in disrespecting anyone's opinions, though I would like maven to thrive and move forward as it did a few years ago. If that happens by community or by coders is immaterial, however progress is important. -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Thursday, July 25, 2013 10:37 AM To: Maven Users List Subject: 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) The Apache Foundation values Community over Code. Merit is thus not just a question about writing the best code but helping and fostering the community around that code. This in deciding committers we need people who are good enough *both* socially and technically. This can be a mix, eg one very good technical person who is poor socially can be counterweighted by a good social person who is (comparatively poor technically... But sufficiently socially aware of their technical ability) If you don't like community over code, then Apache may not be the place for you... And that's ok. But as you step up in engagement with an Apache community, you should be at least ok with the ASF values. How that impacts what it means to be on the PMC is therefore relevant. Should it be a strong step and we only take people into the PMC that repeatedly demonstrate that they value the community over code (large code dumps from long running private forks are not community friendly to a lot of people's mind... Repeatedly causing conflict within the community is another)? Or should we say the PMC is just to perform the legal duty and leave the religion to members of the ASF? That is what needs to be answered On Thursday, 25 July 2013, Sankaran, Nambi wrote: +1 The candidates should be people who contribute in terms of code/patch. -Original Message- From: Jason van Zyl [mailto:ja...@tesla.io] Sent: Thursday, July 25, 2013 9:56 AM To: Maven Users List Subject: 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 12:03 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As part of trying to kick this project back to life, we need to grow both committers and the PMC. You don't need either. You need people who do work. People who do work may happen to be a committer or PMC member but you have it backward. You need a lot of people who do a lot of work to drive a project forward. One of the issues with growing either is determining if potential candidates are the right sort of person. People who do work. I'm not sure how you decide the right sort of person if it's not based in the actual contributions to the project. Not what might be contributed, but what has actually been contributed. There is a disagreement in the PMC as to whether dedication to the Maven project community is relevant to such discussions. Are not people who do work dedicated? Are not people who have done the most work the most dedicated? To me doing work is the whole basis of a meritocracy, doing work is table stakes for being on the PMC and is first condition at least in a meritocracy. For growing committers, this is usually a small issue, if at all. For growing the PMC it can be quite contentious, especially when considering controversial candidates. Discussions should be about the work that is being done on the project. Everything outside of that is not within the purview of the discussion. How can it be? It's generally looking at the contributions over the last 6 months or a year and making a decision based on the merit of that work. In an effort to try and harmonise the PMC, I - as one of the fence sitters - started this debate... In essence calling on that group that trumps the PMC... ie the community. John posted the proposed - remember we are CTR not
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)
+1 On 25/07/2013 11:16 AM, Jason van Zyl wrote: So what's outlined in those paragraphs have counter examples at the ASF. I do not believe it is a bad thing to have alternative distributions or forks, and it doesn't matter where they are. What you are saying is that committers are obliged to share all their work with other committers. Which is more coercion than a matter of choice. For all work that happens within the bounds of the ASF absolutely. Core changes should not be made projects without discussion. That's a good rule and helps with stability. For work that happens outside the bounds of the ASF an author is obliged to do nothing of the sort and the assert as much is absurd quite honestly. What right does the ASF have over work that is not done at Apache? In fact there are people on the ASF Board who belong to companies that have long standing forks and/or alternative distributions of ASF projects. Look at Hadoop: there are two companies that have people on PMCs who maintain alternative distributions with code that does not exist in standard distributions. Both Cloudera and HortonWorks maintain versions of Hadoop that are not compatible and/or have different code than the version from Apache. There is selective patching and additions made to try and provide a better distribution of Hadoop. I don't think this is a bad thing. This also happens with Cassandra and the people who work at Datastax where an alternative distribution is made. I don't know as much about what is in those distributions insofar as code that doesn't exist in the standard Apache distribution. Again, I don't think this is a bad thing. I'm sure they would all tell you that they are trying to make a better version of said project, they work with customers, work at a different pace and hope to integrate their work back in later if possible. If this is a sideways attempt to address what I'm doing in Tesla, which is what it appears like to me, then just start a discussion on the dev list. Happy to discuss it. But if someone posits that all work related to an Apache project has to be done at Apache, then I will say that is a ridiculous supposition and you can find ten counter examples in ten minutes if you went looking. On Jul 25, 2013, at 10:31 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Thursday, 25 July 2013, Curtis Rueden wrote: Hi Stephen and everyone, I largely agree with Nigel, and would add that in general, bureaucratic rules prohibiting various (often technically and/or socially sound) actions such as forking are a great way to ensure that skilled people distance themselves from the organization (i.e., quit the PMC, decline to join, etc.). You will be left with only bureaucrats who can tolerate those restrictions, and worse, create even more of them. Of course, there should be good, publicly stated reasons for long-running forks. I will not speak for the author of the proposed revision, but my understanding of the intent is that these forks should be hosted on ASF hardware in public and as part of our community. It's not about no forking, but allowing the committers to have an ongoing view of things in the community. Any committer is free to edit the wording if they want right now... The doc is a work in progress proposal Merging to mainline is ideal but not always practical in the real world. Developers need the freedom to experiment, even (perhaps especially) when in active community positions such as the PMC. That said, it is certainly the responsibility of those on the PMC to act as community leaders via best practices. But enforcing that in writing, at least as the current proposal does, seems very counterproductive to me. Regards, Curtis On Jul 25, 2013 8:59 AM, Nigel Magnay nigel.mag...@gmail.com wrote: That whole section I find pretty bizarre. - Apache is about (open-source) software. - Writing code is *good*. - Forks are *good* * * I'm put in mind of Linus' talk about why git distribution is so important - that 'if you don't think I'm doing a good job, then you can just take your code from another maintainer. *That's* what keeps a project honest and responsive to the users. I would have thought that the kinds of people who are interested in writing maven-esque code would be some of the people you'd want on a PMC. If they have a long running fork or a reimplementation, surely they would be lobbying for its integration? Merging is also good. If, despite this, they're choosing to do this elsewhere, and/or are having trouble merging projects in, isn't that a pretty sad indictment for the health of the project? Isn't it a bit like saying boo-hoo, those that are doing the actual work might go work in their own sandpit if we won't play ball, let's ex-communicate them ? Unless (as some have suspected for a while) Apache isn't about software anymore, it's about the continued existence of Apache (cfex: OpenOffice).- a political edifice where
Re: maven surefire - selecting providers
Well, I guess you found a bug. TestNG should be able to handle JUnit4 tests, and thus the surefire TestNG provider should be able to hand over the tests in a way that TestNG understands what we want it to do. Would you be so kind and file a bug at https://jira.codehaus.org/browse/SUREFIRE? No need to provide a test case, I already hacked one together myself. ;) Thanks, Andreas 2013/7/25 Andreas Dolk andreas.dolk.mo...@googlemail.com I'm still struggling - I now think that testng really is in mixed mode and tries but fails to execute the jUnit test - maybe, because they use a special runner. Is there any way to disable the mixed mode for a maven build (entirely)? How can I pass that property testng.mixed=false to testng without having to write a testng.xml file (unless it is real trivial...) Best regards, Andreas 2013/7/24 Francesco Mari mari.france...@gmail.com I still wasn't able to reproduce your issue. Looks like TestNG is running in mixed mode [1][2]. The last missing information is the version of JUnit and TestNG you are using. Can you provide this piece of configuration? [1]: http://testng.org/doc/migrating.html [2]: http://testng.org/doc/documentation-main.html#junit 2013/7/24 Andreas Dolk andreas.dolk.mo...@googlemail.com Hi Francesco, I'm using 2.15 And here's the result from a test run, that's what happens. The tests are *only* jUnit tests. I've only replaced path and package names. BTW, the jUnit times are net execution times (unfair!!), testNG reports the total times (fair) ;) The other annoying part is that TestNG picks up far more classes then jUnit... The tests are auto-compiled from jnario specs (jnario.org) which shouldn't make a difference - at the end it's classes compiled from java source files. Regards, Andreas mvn -Dtest=JnSpec* test ... [INFO] --- maven-surefire-plugin:2.15:test (default-test) @ a42-order-be --- [INFO] Surefire report directory: /path/target/surefire-reports [INFO] Using configured provider org.apache.maven.surefire.junitcore.JUnitCoreProvider [INFO] Using configured provider org.apache.maven.surefire.testng.TestNGProvider [INFO] parallel='none', perCoreThreadCount=true, threadCount=2, useUnlimitedThreads=false --- T E S T S --- --- T E S T S --- Running package.JnSpecBPMNProcessSpec Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.199 sec - in package.JnSpecBPMNProcessSpec Running package.JnSpecCreateTheResultMessageOfACancellationSpec Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.485 sec - in package.JnSpecCreateTheResultMessageOfACancellationSpec Running package.JnSpecServicesToSupportCancellationOfItemsOfOneOrderSpec Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.471 sec - in package.JnSpecServicesToSupportCancellationOfItemsOfOneOrderSpec Running package.JnSpecServicesToSupportCancellationOfItemsOfOnePurchaseOrderSpec Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.975 sec - in package.JnSpecServicesToSupportCancellationOfItemsOfOnePurchaseOrderSpec Running package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.262 sec - in package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec Running package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.215 sec - in package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec Running package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.225 sec - in package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec Running package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028 sec - in package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec Results : Tests run: 14, Failures: 0, Errors: 0, Skipped: 0 --- T E S T S --- --- T E S T S
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)
I gather that the process is a simple vote by the existing members. Perhaps this is one of those things that is best left uncodified and allow each person who has to make the decision to chose their own criteria. Clearly people like to work with people that they find intelligent, people whose judgment they trust and people who are fun to work with and people who are willing to do the tasks required to keep the project on track. If someone has additional criteria that they want to apply, I suppose there is not much that you can do about it. If they can persuade others that their criteria matters in a particular case, I suppose a new candidate could be turned down who the minority think should be added. If this criteria eliminates enough good candidates, the project will suffer and another Maven will emerge to take up the space. As an outsider, I personally would not support the inclusion of the criteria and would be hard to persuade that this is grounds for rejection of an otherwise acceptable candidate. Ron On 25/07/2013 12:03 PM, Stephen Connolly wrote: As part of trying to kick this project back to life, we need to grow both committers and the PMC. One of the issues with growing either is determining if potential candidates are the right sort of person. There is a disagreement in the PMC as to whether dedication to the Maven project community is relevant to such discussions. For growing committers, this is usually a small issue, if at all. For growing the PMC it can be quite contentious, especially when considering controversial candidates. In an effort to try and harmonise the PMC, I - as one of the fence sitters - started this debate... In essence calling on that group that trumps the PMC... ie the community. John posted the proposed - remember we are CTR not RTC - addition to the page I started, at least as a stalking horse (or perhaps it is his opinion... I will leave it up to him to state his position) On Thursday, 25 July 2013, Jason van Zyl wrote: So what's outlined in those paragraphs have counter examples at the ASF. I do not believe it is a bad thing to have alternative distributions or forks, and it doesn't matter where they are. What you are saying is that committers are obliged to share all their work with other committers. Which is more coercion than a matter of choice. For all work that happens within the bounds of the ASF absolutely. Core changes should not be made projects without discussion. That's a good rule and helps with stability. For work that happens outside the bounds of the ASF an author is obliged to do nothing of the sort and the assert as much is absurd quite honestly. What right does the ASF have over work that is not done at Apache? In fact there are people on the ASF Board who belong to companies that have long standing forks and/or alternative distributions of ASF projects. Look at Hadoop: there are two companies that have people on PMCs who maintain alternative distributions with code that does not exist in standard distributions. Both Cloudera and HortonWorks maintain versions of Hadoop that are not compatible and/or have different code than the version from Apache. There is selective patching and additions made to try and provide a better distribution of Hadoop. I don't think this is a bad thing. This also happens with Cassandra and the people who work at Datastax where an alternative distribution is made. I don't know as much about what is in those distributions insofar as code that doesn't exist in the standard Apache distribution. Again, I don't think this is a bad thing. I'm sure they would all tell you that they are trying to make a better version of said project, they work with customers, work at a different pace and hope to integrate their work back in later if possible. If this is a sideways attempt to address what I'm doing in Tesla, which is what it appears like to me, then just start a discussion on the dev list. Happy to discuss it. It would be great if you could have that discussion on the dev list any way... But what prompted me to prod John to commit the text and me to start this discussion is a long running debate on the PMC private list as to what kind of person should be on the PMC... By long running I mean that some aspects of this are more than a year old and have been in mails since before you started to re-engage with the project. That does not mean that the stuff you are doing at Tesla is not relevant or a trigger for trying to sort out the disconnect between two camps in the PMC... More that it is being considered in a common context of an ongoing debate, and in an effort to resolve the debate we are asking those we are supposed to serve for their input. HTH But if someone posits that all work related to an Apache project has to be done at Apache, then I will say that is a ridiculous supposition and you can find ten counter examples in ten minutes if you went looking. On Jul 25, 2013, at 10:31 AM,
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)
The last thing that you need is a bunch of smart committed people who talk about doing stuff the Apache way but don't actually write code or participate in supporting users. If someone is writing code that works, faster than the rest of the team can read it, you are in a great position. Get more code readers! If someone is generating more ideas for improvement than the team can evaluate, then add more marketing/analyst types to the committee. Ron On 25/07/2013 12:56 PM, Jason van Zyl wrote: On Jul 25, 2013, at 12:03 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As part of trying to kick this project back to life, we need to grow both committers and the PMC. You don't need either. You need people who do work. People who do work may happen to be a committer or PMC member but you have it backward. You need a lot of people who do a lot of work to drive a project forward. One of the issues with growing either is determining if potential candidates are the right sort of person. People who do work. I'm not sure how you decide the right sort of person if it's not based in the actual contributions to the project. Not what might be contributed, but what has actually been contributed. There is a disagreement in the PMC as to whether dedication to the Maven project community is relevant to such discussions. Are not people who do work dedicated? Are not people who have done the most work the most dedicated? To me doing work is the whole basis of a meritocracy, doing work is table stakes for being on the PMC and is first condition at least in a meritocracy. For growing committers, this is usually a small issue, if at all. For growing the PMC it can be quite contentious, especially when considering controversial candidates. Discussions should be about the work that is being done on the project. Everything outside of that is not within the purview of the discussion. How can it be? It's generally looking at the contributions over the last 6 months or a year and making a decision based on the merit of that work. In an effort to try and harmonise the PMC, I - as one of the fence sitters - started this debate... In essence calling on that group that trumps the PMC... ie the community. John posted the proposed - remember we are CTR not RTC - addition to the page I started, at least as a stalking horse (or perhaps it is his opinion... I will leave it up to him to state his position) On Thursday, 25 July 2013, Jason van Zyl wrote: So what's outlined in those paragraphs have counter examples at the ASF. I do not believe it is a bad thing to have alternative distributions or forks, and it doesn't matter where they are. What you are saying is that committers are obliged to share all their work with other committers. Which is more coercion than a matter of choice. For all work that happens within the bounds of the ASF absolutely. Core changes should not be made projects without discussion. That's a good rule and helps with stability. For work that happens outside the bounds of the ASF an author is obliged to do nothing of the sort and the assert as much is absurd quite honestly. What right does the ASF have over work that is not done at Apache? In fact there are people on the ASF Board who belong to companies that have long standing forks and/or alternative distributions of ASF projects. Look at Hadoop: there are two companies that have people on PMCs who maintain alternative distributions with code that does not exist in standard distributions. Both Cloudera and HortonWorks maintain versions of Hadoop that are not compatible and/or have different code than the version from Apache. There is selective patching and additions made to try and provide a better distribution of Hadoop. I don't think this is a bad thing. This also happens with Cassandra and the people who work at Datastax where an alternative distribution is made. I don't know as much about what is in those distributions insofar as code that doesn't exist in the standard Apache distribution. Again, I don't think this is a bad thing. I'm sure they would all tell you that they are trying to make a better version of said project, they work with customers, work at a different pace and hope to integrate their work back in later if possible. If this is a sideways attempt to address what I'm doing in Tesla, which is what it appears like to me, then just start a discussion on the dev list. Happy to discuss it. It would be great if you could have that discussion on the dev list any way... But what prompted me to prod John to commit the text and me to start this discussion is a long running debate on the PMC private list as to what kind of person should be on the PMC... By long running I mean that some aspects of this are more than a year old and have been in mails since before you started to re-engage with the project. That does not mean that the stuff you are doing at Tesla is not relevant or a trigger for trying to
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 Thursday, 25 July 2013, Ron Wheeler wrote: The last thing that you need is a bunch of smart committed people who talk about doing stuff the Apache way but don't actually write code or participate in supporting users. The key thing is it is not just about writing code. We need people to help on the mailing lists We need people to identify bogus/valid bug reports We need people to document how to use/extend maven Also somebody else said they think maven needs a strong leader... The ASF does not want a single leader for a project. The closest you might get is the PMC as a whole. There is no dictator in an Apache project (benevolent or not) From outside you might think the PMC Chair is the leader... Wrong, they are just the (un)lucky victim that gets the legal responsibilities that the ASF board needs to vest in an officer of the foundation... The PMC chair is there *to serve* the PMC. Right now there is a need for strong leadership of this project. While the project remains at the ASF that means a strong PMC... And right now this is a PMC somewhat fractured over the core issue I started this thread with... If you want to help this project, I suggest you engage this debate... Saying it is the wrong debate actually misses the point and will just further the festering that has lead some to disengage from this project. There are other debates we can and should have, but right now this is one we *need* to have, not because I want to have it, or because I enjoy this type of debate, but because we have reached a stagnant position and it needs to change... I don't mind which direction too much mind If someone is writing code that works, faster than the rest of the team can read it, you are in a great position. Get more code readers! If someone is generating more ideas for improvement than the team can evaluate, then add more marketing/analyst types to the committee. Ron On 25/07/2013 12:56 PM, Jason van Zyl wrote: On Jul 25, 2013, at 12:03 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: As part of trying to kick this project back to life, we need to grow both committers and the PMC. You don't need either. You need people who do work. People who do work may happen to be a committer or PMC member but you have it backward. You need a lot of people who do a lot of work to drive a project forward. One of the issues with growing either is determining if potential candidates are the right sort of person. People who do work. I'm not sure how you decide the right sort of person if it's not based in the actual contributions to the project. Not what might be contributed, but what has actually been contributed. There is a disagreement in the PMC as to whether dedication to the Maven project community is relevant to such discussions. Are not people who do work dedicated? Are not people who have done the most work the most dedicated? To me doing work is the whole basis of a meritocracy, doing work is table stakes for being on the PMC and is first condition at least in a meritocracy. For growing committers, this is usually a small issue, if at all. For growing the PMC it can be quite contentious, especially when considering controversial candidates. Discussions should be about the work that is being done on the project. Everything outside of that is not within the purview of the discussion. How can it be? It's generally looking at the contributions over the last 6 months or a year and making a decision based on the merit of that work. In an effort to try and harmonise the PMC, I - as one of the fence sitters - started this debate... In essence calling on that group that trumps the PMC... ie the community. John posted the proposed - remember we are CTR not RTC - addition to the page I started, at least as a stalking horse (or perhaps it is his opinion... I will leave it up to him to state his position) On Thursday, 25 July 2013, Jason van Zyl wrote: So what's outlined in those paragraphs have counter examples at the ASF. I do not believe it is a bad thing to have alternative distributions or forks, and it doesn't matter where they are. What you are saying is that committers are obliged to share all their work with other committers. Which is more coercion than a matter of choice. For all work that happens within the bounds of the ASF absolutely. Core changes should not be made projects without discussion. That's a good rule and helps with stability. For work that happens outside the bounds of the ASF an author is obliged to do nothing of the sort and the assert as much is absurd quite honestly. What right does the ASF have over work that is not done at Apache? In fact there are people on the ASF Board who belong to companies that have long standing forks and/or alternative distributions of ASF projects. Look at Hadoop: there are two companies that have people on PMCs who maintain alternative distributions with code that
Re: Maven / javac does not compile classes to target folder
wayne, thanks a lot for your response, it helped to figure out what's going on. it's indeed javac that aborts (yes aborts, no error, it just quits). something with annotations in enum constructors, it's not reported to the javac mailing list http://mail.openjdk.java.net/pipermail/compiler-dev/2013-July/006902.html i was wondering if maven could detect that javac does not end successfully, and then abort and blame the compilation directly instead of building an empty jar and going on, which takes longer to find the real issue. but then again i seem to be the only person affected by this ... i've found a workaround for my compilation, so for me the case is closed. thanks again! On Thu, Jul 25, 2013 at 3:45 AM, Wayne Fay wayne...@gmail.com wrote: Any hint what to try next or an idea for a workaround much appreciated *sigh* In the future, sighs are unnecessary. The culprit is that the compilation puts nothing into the target folder, even though it says it compiles the 217 classes. No error whatsoever. Maybe the words Stale source detected ring some bells? Can you please try mvn -X compile and then copy/paste the javac line that Maven shows you to see if this works/compiles fine with javac or not? If it works with javac with no issues, then we probably have a Maven issue somewhere. But if javac doesn't like it, then you can't really expect Maven to do much for you. You said it works in IntelliJ but this does not necessarily tell me that it works in plain command-line javac. There are lots of things that IDEs do to help people out. Please test that first. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven surefire - selecting providers
I hope it's a bug and that it's easy to fix :) Would be great if I could keep TestNG and use jnario in the same project! Here is the ticket reference: https://jira.codehaus.org/browse/SUREFIRE-1019 Thanks! Andreas 2013/7/25 Andreas Gudian andreas.gud...@gmail.com Well, I guess you found a bug. TestNG should be able to handle JUnit4 tests, and thus the surefire TestNG provider should be able to hand over the tests in a way that TestNG understands what we want it to do. Would you be so kind and file a bug at https://jira.codehaus.org/browse/SUREFIRE? No need to provide a test case, I already hacked one together myself. ;) Thanks, Andreas 2013/7/25 Andreas Dolk andreas.dolk.mo...@googlemail.com I'm still struggling - I now think that testng really is in mixed mode and tries but fails to execute the jUnit test - maybe, because they use a special runner. Is there any way to disable the mixed mode for a maven build (entirely)? How can I pass that property testng.mixed=false to testng without having to write a testng.xml file (unless it is real trivial...) Best regards, Andreas 2013/7/24 Francesco Mari mari.france...@gmail.com I still wasn't able to reproduce your issue. Looks like TestNG is running in mixed mode [1][2]. The last missing information is the version of JUnit and TestNG you are using. Can you provide this piece of configuration? [1]: http://testng.org/doc/migrating.html [2]: http://testng.org/doc/documentation-main.html#junit 2013/7/24 Andreas Dolk andreas.dolk.mo...@googlemail.com Hi Francesco, I'm using 2.15 And here's the result from a test run, that's what happens. The tests are *only* jUnit tests. I've only replaced path and package names. BTW, the jUnit times are net execution times (unfair!!), testNG reports the total times (fair) ;) The other annoying part is that TestNG picks up far more classes then jUnit... The tests are auto-compiled from jnario specs (jnario.org) which shouldn't make a difference - at the end it's classes compiled from java source files. Regards, Andreas mvn -Dtest=JnSpec* test ... [INFO] --- maven-surefire-plugin:2.15:test (default-test) @ a42-order-be --- [INFO] Surefire report directory: /path/target/surefire-reports [INFO] Using configured provider org.apache.maven.surefire.junitcore.JUnitCoreProvider [INFO] Using configured provider org.apache.maven.surefire.testng.TestNGProvider [INFO] parallel='none', perCoreThreadCount=true, threadCount=2, useUnlimitedThreads=false --- T E S T S --- --- T E S T S --- Running package.JnSpecBPMNProcessSpec Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.199 sec - in package.JnSpecBPMNProcessSpec Running package.JnSpecCreateTheResultMessageOfACancellationSpec Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.485 sec - in package.JnSpecCreateTheResultMessageOfACancellationSpec Running package.JnSpecServicesToSupportCancellationOfItemsOfOneOrderSpec Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.471 sec - in package.JnSpecServicesToSupportCancellationOfItemsOfOneOrderSpec Running package.JnSpecServicesToSupportCancellationOfItemsOfOnePurchaseOrderSpec Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.975 sec - in package.JnSpecServicesToSupportCancellationOfItemsOfOnePurchaseOrderSpec Running package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.262 sec - in package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec Running package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.215 sec - in package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec Running package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.225 sec - in package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnAlreadyDeliveredOrderitemSpec Running package.JnSpecVerifyingTheCancellationMessageACancelRequestWithAnUndeliveredOrderitemSpec Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028 sec - in
Re: Maven / javac does not compile classes to target folder
wayne, thanks a lot for your response, it helped to figure out what's going on. I'm very glad to hear it! i was wondering if maven could detect that javac does not end successfully, and then abort and blame the compilation directly instead of building an I agree this sounds like a reasonable change to Maven. I'm a bit surprised it is not already handled -- you'd think javac would error with a status indicating error which Maven would pick up and report back to the user. If you have a few minutes, could I convince you to post a JIRA defect against hmmm maven-compiler-plugin or perhaps plexus-compiler? This assumes you have a Xircles account etc. i've found a workaround for my compilation, so for me the case is closed. thanks again! Could you let us know the workaround, so if/when someone else has this trouble, they know what to do about it? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
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 26 July 2013 03:25, Andreas Gudian andreas.gud...@gmail.com wrote: I tend to agree with Jason: the PMC needs people who *do* stuff, meaning: * bring the project foward (with discussions like this one, or the JDK5/JDK6 threads). * keep a close eye on commits. * keep a very close eye on release votes. * continue to assure that we don't do anything that the ASFdoesn't allow, while making sure that we don't burden ourselfs with bulky processes to achieve that. Part of this discussion is also to draw the line between PMC and committer. All but the last point (about ASF) can be done by committers. A PMC member is no more powerful than a committer (in terms of commit access). It is however the PMC vote that is binding (See http://www.apache.org/foundation/voting.html). - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
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)
Hi, I think the point is quite simple. I agree with Jason that work should be the main criteria if not the only one. But as Stephen reminds, we should define work in a larger general sense than just code. Working for the community as worshipped by the ASF can be pushing code, sure, but also helping people in many manners : docs, ml, etc. Cheers Le 25 juil. 2013 22:32, Paul Benedict pbened...@apache.org a écrit : 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 us your thoughts. The topic is essentially: Do you want the members of the Maven PMC to be social leaders of the Maven community, who's actions demonstrate the best community behaviour? The alternative is that members of the Maven PMC are here purely to complete the legal requirements that an Apache TLP has delegated to PMCs This is not black and white... The answer can be grey... And everyone is human so can make mistakes... So community, what are you expecting? - Stephen Connolly On Thursday, 25 July 2013, wrote: Author: jdcasey Date: Wed Jul 24 23:21:58 2013 New Revision: 1506778 URL: http://svn.apache.org/r1506778 Log: Adding section on PMC standards of community commitment Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project -roles.md?rev=1506778r1=1506777r2=1506778view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24 23:21:58 2013 @@ -176,6 +176,29 @@ The Project Management Committee has the * Voting on release artifacts. * !-- TODO: get the rest of these -- + Standards for Community Commitment + +In the spirit of supporting the health of our community, Project +Management Committee members refrain from actions that subvert the +functioning of the committee itself. + +First, Project Management Committee members should not maintain long-running +forks of Maven code outside of the project itself. Making significant +changes to Maven code outside of the project displays a lack of +investment in the community. Additionally, attempting to re-integrate +a large number of code changes in bulk overwhelms the ability of +volunteers in the community to review (and potentially veto) the +changes. This effectively thwarts the policing function of the PMC. + +Second, Project Management Committee members should not divert work +on redesigning, reimplementing, or improving Maven code to +alternative projects outside of this community for the purposes of +reintroducing them as replacement for existing Maven code. While +there is a danger here of falling into a Not Invented Here mentality, +new projects +created by Maven PMC members strictly to replace Maven code should +not be allowed. + ### [Project Management Chair]( http://www.apache.org/foundation/how-it-works.html#pmc-chair) For various legal reasons, there are certain things that the Apache -- Sent from my phone - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Cheers, Paul
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)
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)? 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) ) 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 us your thoughts. The topic is essentially: Do you want the members of the Maven PMC to be social leaders of the Maven community, who's actions demonstrate the best community behaviour? The alternative is that members of the Maven PMC are here purely to complete the legal requirements that an Apache TLP has delegated to PMCs This is not black and white... The answer can be grey... And everyone is human so can make mistakes... So community, what are you expecting? - Stephen Connolly On Thursday, 25 July 2013, wrote: Author: jdcasey Date: Wed Jul 24 23:21:58 2013 New Revision: 1506778 URL: http://svn.apache.org/r1506778 Log: Adding section on PMC standards of community commitment Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project -roles.md?rev=1506778r1=1506777r2=1506778view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24 23:21:58 2013 @@ -176,6 +176,29 @@ The Project Management Committee has the * Voting on release artifacts. * !-- TODO: get the rest of these -- + Standards for Community Commitment + +In the spirit of supporting the health of our community, Project +Management Committee members refrain from actions that subvert the +functioning of the committee itself. + +First, Project Management Committee members should not maintain long-running +forks of Maven code outside of the project itself. Making significant +changes to Maven code outside of the project displays a lack of +investment in the community. Additionally, attempting to re-integrate +a large number of code changes in bulk overwhelms the ability of +volunteers in the community to review (and potentially veto) the +changes. This effectively thwarts the policing function of the PMC. + +Second, Project Management Committee members should not divert work +on redesigning, reimplementing, or improving Maven code to +alternative projects outside of this community for the purposes of +reintroducing them as replacement
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 25 July 2013 22:17, Paul Benedict pbened...@apache.org wrote: Stephen, those are great questions. Yet, I think these questions are riding an assumption that PMC members are solely volunteering at Apache, because the emphasis (as I interpret your words) is to place the Apache project first/above other external contributions. Isn't that the heart of this debate? A person who solely contributes to Apache and no other OS organizations has no divided loyalties -- they do all their work here. But what happens when contributions are here and elsewhere? If they feel they cannot resolve any conflict between their role on the PMC and any responsibilities the Maven community decide are part and parcel of that role with their roles in other projects, then quite simply they can just step down from the PMC and remain a committer. There is no shame in so doing. Which brings us back to what does the community expect from its PMC? I ask rhetorically, to solicit answers, of course... and I see where this is going and what historical processes within Maven are being addressed. On Thu, Jul 25, 2013 at 4: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)? 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) ) 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 us your thoughts. The topic is essentially: Do you want the members of the Maven PMC to be social leaders of the Maven community, who's actions demonstrate the best community behaviour? The alternative is that members of the Maven PMC are here purely to complete the legal requirements that an Apache TLP has delegated to PMCs This is not black and white... The answer can be grey... And everyone is human so can make mistakes... So community, what are you expecting? - Stephen Connolly On Thursday, 25 July 2013, wrote: Author: jdcasey Date: Wed Jul 24 23:21:58 2013 New Revision: 1506778 URL: http://svn.apache.org/r1506778 Log: Adding section on PMC standards of community commitment Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project
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 7/25/13 4:17 PM, Paul Benedict wrote: Stephen, those are great questions. Yet, I think these questions are riding an assumption that PMC members are solely volunteering at Apache, because the emphasis (as I interpret your words) is to place the Apache project first/above other external contributions. Isn't that the heart of this debate? A person who solely contributes to Apache and no other OS organizations has no divided loyalties -- they do all their work here. But what happens when contributions are here and elsewhere? I ask rhetorically, to solicit answers, of course... and I see where this is going and what historical processes within Maven are being addressed. I don't think it's about whether you contribute elsewhere or not. It's about whether you expect to do a ton of work outside the community here, outside the commit logs and the review, in order to avoid the discussion and potential for veto. Working in this way opens the possibility for changing the rules for who gets to contribute, especially when code diverges for long periods then gets reconciled with a massive rebase. ASF is supposed to be about more than code. We're supposed to be working together on this project. I feel like the above hamstrings that whole process. And note: I'm only suggesting that the PMC - who is supposed to have the long-term interests of *this* project at heart - be held to a higher standard, to provide an example for the rest of the project. This is not saying you're stuck working solely within Maven just because you're on the PMC; it's saying that you should promote the health of the community by making sure the processes in place work as well as possible. ASF membership is supposed to be reserved for those who get the Apache Way, and I've heard it said that PMC membership should imply ASF membership. IMO, working for extended periods outside of the venues for our community is not consistent with having the best interests of this project in mind. On Thu, Jul 25, 2013 at 4: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)? 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) ) 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 us your thoughts. The topic is essentially: Do you want the members of the Maven PMC to be social leaders of the Maven community, who's actions demonstrate the best community behaviour? The alternative is that members of the Maven PMC are here purely to complete the legal requirements that an Apache TLP has delegated to PMCs
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)
Stephen, those are great questions. Yet, I think these questions are riding an assumption that PMC members are solely volunteering at Apache, because the emphasis (as I interpret your words) is to place the Apache project first/above other external contributions. Isn't that the heart of this debate? A person who solely contributes to Apache and no other OS organizations has no divided loyalties -- they do all their work here. But what happens when contributions are here and elsewhere? I ask rhetorically, to solicit answers, of course... and I see where this is going and what historical processes within Maven are being addressed. On Thu, Jul 25, 2013 at 4: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)? 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) ) 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 us your thoughts. The topic is essentially: Do you want the members of the Maven PMC to be social leaders of the Maven community, who's actions demonstrate the best community behaviour? The alternative is that members of the Maven PMC are here purely to complete the legal requirements that an Apache TLP has delegated to PMCs This is not black and white... The answer can be grey... And everyone is human so can make mistakes... So community, what are you expecting? - Stephen Connolly On Thursday, 25 July 2013, wrote: Author: jdcasey Date: Wed Jul 24 23:21:58 2013 New Revision: 1506778 URL: http://svn.apache.org/r1506778 Log: Adding section on PMC standards of community commitment Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project -roles.md?rev=1506778r1=1506777r2=1506778view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24 23:21:58 2013 @@ -176,6 +176,29 @@ The Project Management Committee has the * Voting on release artifacts. * !-- TODO: get the rest of these -- + Standards for Community Commitment + +In the spirit of supporting the health of our community, Project +Management Committee members
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)
Agreed. I'll tip my hand and give my opinion: PMC members should have an Apache first mentality. They are gatekeepers and guardians of their project. Spinning off critical code to other OSS organizations should be frowned upon -- it splits the development and wider community into smaller pieces. NB: My original response was just criticism of the commitment wording. It's nice to say what commitments PMC members should have, but if there's no way to enforce it, it puts into question why the commitments are even expected. AFAIK, merit at Apache is forever -- you can't have it undone. If someone loses their Apache first spirit and begins critical development elsewhere, what can be done about it? Are there any practical recourses? I don't think there is which is why Maven development has that problem today. On Thu, Jul 25, 2013 at 4:36 PM, John Casey jdca...@commonjava.org wrote: On 7/25/13 4:17 PM, Paul Benedict wrote: Stephen, those are great questions. Yet, I think these questions are riding an assumption that PMC members are solely volunteering at Apache, because the emphasis (as I interpret your words) is to place the Apache project first/above other external contributions. Isn't that the heart of this debate? A person who solely contributes to Apache and no other OS organizations has no divided loyalties -- they do all their work here. But what happens when contributions are here and elsewhere? I ask rhetorically, to solicit answers, of course... and I see where this is going and what historical processes within Maven are being addressed. I don't think it's about whether you contribute elsewhere or not. It's about whether you expect to do a ton of work outside the community here, outside the commit logs and the review, in order to avoid the discussion and potential for veto. Working in this way opens the possibility for changing the rules for who gets to contribute, especially when code diverges for long periods then gets reconciled with a massive rebase. ASF is supposed to be about more than code. We're supposed to be working together on this project. I feel like the above hamstrings that whole process. And note: I'm only suggesting that the PMC - who is supposed to have the long-term interests of *this* project at heart - be held to a higher standard, to provide an example for the rest of the project. This is not saying you're stuck working solely within Maven just because you're on the PMC; it's saying that you should promote the health of the community by making sure the processes in place work as well as possible. ASF membership is supposed to be reserved for those who get the Apache Way, and I've heard it said that PMC membership should imply ASF membership. IMO, working for extended periods outside of the venues for our community is not consistent with having the best interests of this project in mind. On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly stephen.alan.connolly@gmail.**com 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)? 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) ) 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
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)
Private Sector Usage of Apache code: Sonatype is the second organization (that I know of) to leverage existing ASF code to engage Paying Customers In last 10 years Paul F (dba WS02) leveraged the entire axis project for Customised SAAS Solutions for HealthCare as well as Financial Services WS02's contributions of features and functions were merged back in to axis code base.. Also WS02 employees constituted +50% effort for re-architecture from Axis1 to Axis2 (quite similar to the way Sonatype contributes Architecture, Doc and code back to Maven) Subsidising ASF volunteer efforts: As some of us age and when (and if) the government pittance starts to kick in (hopefully BEFORE Govt pittance money runs out) I would expect even greater Apache participation by those committers on bugfixes, support, documentation as well as fix and testing new features and functions Social Media: Someone mentioned the freshest maven committers *should* maintain feeds to/from Social Media I could see support updates to twitter (with some manner of RSS feed?) not sure if support feeds are happening now to Twitter or another provider ? Architecture changes should be contributed to existing arch doc . Resulting architecture doc updates to Social Media avenues *could* possibly be somehow uploaded to Facebook Does Maven have a facebook account? My 2 cents, Martin __ Date: Thu, 25 Jul 2013 16:55:39 -0500 Subject: 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) From: pbened...@apache.org To: jdca...@commonjava.org; stephen.alan.conno...@gmail.com CC: d...@maven.apache.org; users@maven.apache.org Agreed. I'll tip my hand and give my opinion: PMC members should have an Apache first mentality. They are gatekeepers and guardians of their project. Spinning off critical code to other OSS organizations should be frowned upon -- it splits the development and wider community into smaller pieces. NB: My original response was just criticism of the commitment wording. It's nice to say what commitments PMC members should have, but if there's no way to enforce it, it puts into question why the commitments are even expected. AFAIK, merit at Apache is forever -- you can't have it undone. If someone loses their Apache first spirit and begins critical development elsewhere, what can be done about it? Are there any practical recourses? I don't think there is which is why Maven development has that problem today. On Thu, Jul 25, 2013 at 4:36 PM, John Casey jdca...@commonjava.org wrote: On 7/25/13 4:17 PM, Paul Benedict wrote: Stephen, those are great questions. Yet, I think these questions are riding an assumption that PMC members are solely volunteering at Apache, because the emphasis (as I interpret your words) is to place the Apache project first/above other external contributions. Isn't that the heart of this debate? A person who solely contributes to Apache and no other OS organizations has no divided loyalties -- they do all their work here. But what happens when contributions are here and elsewhere? I ask rhetorically, to solicit answers, of course... and I see where this is going and what historical processes within Maven are being addressed. I don't think it's about whether you contribute elsewhere or not. It's about whether you expect to do a ton of work outside the community here, outside the commit logs and the review, in order to avoid the discussion and potential for veto. Working in this way opens the possibility for changing the rules for who gets to contribute, especially when code diverges for long periods then gets reconciled with a massive rebase. ASF is supposed to be about more than code. We're supposed to be working together on this project. I feel like the above hamstrings that whole process. And note: I'm only suggesting that the PMC - who is supposed to have the long-term interests of *this* project at heart - be held to a higher standard, to provide an example for the rest of the project. This is not saying you're stuck working solely within Maven just because you're on the PMC; it's saying that you should promote the health of the community by making sure the processes in place work as well as possible. ASF membership is supposed to be reserved for those who get the Apache Way, and I've heard it said that PMC membership should imply ASF membership. IMO, working for extended periods outside of the venues for our community is not consistent with having the best interests of this project in mind. On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly stephen.alan.connolly@gmail.**com stephen.alan.conno...@gmail.com wrote: Perhaps we could reframe the question a little then (as people seem to be testing
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)
Maven is open source and anyone can do whatever they want with it. That is the whole point of the Apache license. If the code splits off and a new open source product emerges that is better than Maven, then we all win. To prevent this, the Maven PMC has to make the right choices about the Maven roadmap and make sure that the committers see a vision that they regard as worth devoting time to. If the code splits off and a commercial product emerges, how does that affect Maven? Why would it be better if the person was not on the PMC? If the code splits and the PMC was right about the proper strategy, the fork will die a natural death or become a niche solution which may take pressure of the Maven PMC to handle special cases that are not important to the main user community. The people who want to pursue a fork will do that anyway so whether they stay in the PMC or do not, makes no difference to the Maven team. The wider community will go with the better package so the Maven PMC has to make good choices. Ron On 25/07/2013 5:55 PM, Paul Benedict wrote: Agreed. I'll tip my hand and give my opinion: PMC members should have an Apache first mentality. They are gatekeepers and guardians of their project. Spinning off critical code to other OSS organizations should be frowned upon -- it splits the development and wider community into smaller pieces. NB: My original response was just criticism of the commitment wording. It's nice to say what commitments PMC members should have, but if there's no way to enforce it, it puts into question why the commitments are even expected. AFAIK, merit at Apache is forever -- you can't have it undone. If someone loses their Apache first spirit and begins critical development elsewhere, what can be done about it? Are there any practical recourses? I don't think there is which is why Maven development has that problem today. On Thu, Jul 25, 2013 at 4:36 PM, John Casey jdca...@commonjava.org wrote: On 7/25/13 4:17 PM, Paul Benedict wrote: Stephen, those are great questions. Yet, I think these questions are riding an assumption that PMC members are solely volunteering at Apache, because the emphasis (as I interpret your words) is to place the Apache project first/above other external contributions. Isn't that the heart of this debate? A person who solely contributes to Apache and no other OS organizations has no divided loyalties -- they do all their work here. But what happens when contributions are here and elsewhere? I ask rhetorically, to solicit answers, of course... and I see where this is going and what historical processes within Maven are being addressed. I don't think it's about whether you contribute elsewhere or not. It's about whether you expect to do a ton of work outside the community here, outside the commit logs and the review, in order to avoid the discussion and potential for veto. Working in this way opens the possibility for changing the rules for who gets to contribute, especially when code diverges for long periods then gets reconciled with a massive rebase. ASF is supposed to be about more than code. We're supposed to be working together on this project. I feel like the above hamstrings that whole process. And note: I'm only suggesting that the PMC - who is supposed to have the long-term interests of *this* project at heart - be held to a higher standard, to provide an example for the rest of the project. This is not saying you're stuck working solely within Maven just because you're on the PMC; it's saying that you should promote the health of the community by making sure the processes in place work as well as possible. ASF membership is supposed to be reserved for those who get the Apache Way, and I've heard it said that PMC membership should imply ASF membership. IMO, working for extended periods outside of the venues for our community is not consistent with having the best interests of this project in mind. On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly stephen.alan.connolly@gmail.**com 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)? 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
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 25/07/2013 5:32 PM, Stephen Connolly wrote: On 25 July 2013 22:17, Paul Benedict pbened...@apache.org wrote: Stephen, those are great questions. Yet, I think these questions are riding an assumption that PMC members are solely volunteering at Apache, because the emphasis (as I interpret your words) is to place the Apache project first/above other external contributions. Isn't that the heart of this debate? A person who solely contributes to Apache and no other OS organizations has no divided loyalties -- they do all their work here. But what happens when contributions are here and elsewhere? If they feel they cannot resolve any conflict between their role on the PMC and any responsibilities the Maven community decide are part and parcel of that role with their roles in other projects, then quite simply they can just step down from the PMC and remain a committer. There is no shame in so doing. Which brings us back to what does the community expect from its PMC? I can only speak for me. I expect the committee to: - Maintain a coherent roadmap that makes sense to the majority of the community - To communicate the roadmap to the community and listen to the feedback - To ensure that the releases are complete - code tested and documentation updated - To coordinate the activities of the committers to ensure that they are meeting the technical standards and completing the release functionality and docs according to the agreed schedule. - To ensure that the project committers are enjoying working together and that disagreements are worked on in a professional way. Ron I ask rhetorically, to solicit answers, of course... and I see where this is going and what historical processes within Maven are being addressed. On Thu, Jul 25, 2013 at 4: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)? 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) ) 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 us your thoughts. The topic is essentially: Do you want the members of the Maven PMC to be social leaders of the Maven community, who's actions demonstrate the best community behaviour? The alternative is that members of the Maven PMC are here purely to complete the legal requirements that an Apache TLP has delegated to PMCs This is not black and white... The answer can be grey... And everyone is human so can make mistakes... So community, what are you expecting? - Stephen Connolly On Thursday, 25 July 2013, wrote: Author: jdcasey Date: Wed Jul 24
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 25/07/2013 5:05 PM, Stephen Connolly 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)? No. 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) ) Don't see this as helping the community. 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) Some of these can be discussed in the user community if there is not an obvious answer. -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 us your thoughts. The topic is essentially: Do you want the members of the Maven PMC to be social leaders of the Maven community, who's actions demonstrate the best community behaviour? The alternative is that members of the Maven PMC are here purely to complete the legal requirements that an Apache TLP has delegated to PMCs This is not black and white... The answer can be grey... And everyone is human so can make mistakes... So community, what are you expecting? - Stephen Connolly On Thursday, 25 July 2013, wrote: Author: jdcasey Date: Wed Jul 24 23:21:58 2013 New Revision: 1506778 URL: http://svn.apache.org/r1506778 Log: Adding section on PMC standards of community commitment Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project -roles.md?rev=1506778r1=1506777r2=1506778view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24 23:21:58 2013 @@ -176,6 +176,29 @@ The Project Management Committee has the * Voting on release artifacts. * !-- TODO: get the rest of these -- + Standards for Community Commitment + +In the spirit of supporting the health of our community, Project +Management Committee members refrain from actions that subvert the +functioning of the committee itself. + +First, Project Management Committee members should not maintain long-running +forks of Maven code outside of the project itself. Making significant +changes to Maven code outside of the project displays a lack of +investment in the community. Additionally, attempting to re-integrate +a large number of code changes in bulk overwhelms the ability of +volunteers in the community to review (and potentially veto) the +changes. This effectively thwarts the policing function of the PMC. + +Second, Project Management Committee members should not divert work +on redesigning, reimplementing, or improving Maven code to +alternative projects outside of this community for the purposes of +reintroducing them as replacement
