This community is a Meritocracy, not a Democracy. "What's the difference?", you ask.
In a Democracy you have a vote, you can cast your vote for various reasons, no one asks "why" if you vote a certain way. There's no abstract idea of "merit". At Apache you certainly have a "vote" in a consensus-based approach to collaboration, but no one has license to -1 without an argument "on the merits". This is what makes the community a Meritocracy. If you disagree with Peter's initiative, you'll need to provide a few things for your veto to "stick": 1. A detailed set of objections to which Peter should be able to respond. 2. Some justification as to why the community would reject initiative? 3. A reasonable attempt to understand the merit of a particular proposal. I think the "maven is a road to hell" rhetoric violates the necessary sense of decorum that enables a group of volunteers to work together. It runs counter to the ideas the Foundation (supposedly) adheres to. If you are really casting a veto on peter's initiative stand up and present a viable counter-argument. If you don't I do believe the the community should disregard you previous email. Tim O'Brien On Nov 25, 2010, at 12:46 PM, Peter Lin <[email protected]> wrote: > > I hate maven and it sucks. It does not reduce maintenance at all. I vote > against changing to maven. > > -1 > > Maven is a road to he'll on my book > > Sent from my iPhone > > On Nov 25, 2010, at 1:28 PM, sebb <[email protected]> wrote: > >> On 25 November 2010 17:54, Peter Lynch <[email protected]> wrote: >>> Hi sebb, >>> >>> On Thu, Nov 25, 2010 at 9:42 AM, sebb <[email protected]> wrote: >>> >>>> On 25 November 2010 14:18, Peter Lynch <[email protected]> wrote: >>>>> I am wondering if there is developer support for the idea of converting >>>>> JMeter's build process to be based on Maven. If there is suitable support >>>> of >>>>> this idea, I was going to start writing a conversion script that would >>>>> convert the project sources while maintaining as much scm history as >>>>> possible. >>>> >>>> Should be possible to maintain all SCM history if done properly. >>>> >>>> Note that changes of source layout will cause a (one-off) problem for >>>> people who maintain private patches. >>>> >>>>> I have outlined some of the advantages this offers in this enhancement >>>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50324 >>>>> >>>>> <https://issues.apache.org/bugzilla/show_bug.cgi?id=50324> >>>>> So what do the developers think? >>>> >>>> Why do you want to build JMeter with Maven? >>>> >>>> >>> I'd like JMeter to be accessible to as many developers as possible. I'd like >>> the source code layout to be more standardized, to be more accessible to >>> Java developers who want to contribute to the project. I'd like to fix >>> problems in JMeter source code by opening the project in any IDE that >>> supports Maven project structures and know instantly how to run tests, build >>> and deploy. I'd like the artifacts that JMeter produces to be in a format >>> that can be more easily reused and referenced by other projects. >>> >>> >>>> Is it just so that JMeter jars can be uploaded to Maven Central? >>>> If so, then there are simpler ways to achieve this. >>>> >>>> >>> No that is not the primary reason, see above. I am familiar with how to get >>> jars on Central using various methods - I work at Sonatype afterall ;). >>> >>> Is it so that you can run JMeter with Maven (assuming jars are in Central)? >>> >>> If so, then potentially major changes are needed to JMeter, because >>>> currently it maintains its own classpath, and expects to find jars in >>>> specific locations. >>>> For example, lib/ext is searched for JMeter components; lib is not. >>>> Since JMeter has to do quite a lot of jar scanning, it is important >>>> that this is efficient. >>>> >>> >>> You bring up some good points but all of this is scope creep - it may come >>> as an eventual side effect but that is not the main goal. >> >> This is not scope creep - if the above mentioned issues are not >> addressed, then JMeter either won't work or will be slowed down. >> >>> It may turn out >>> that during the conversion process there is some roadblock that would >>> prevent Maven being useful - but I doubt it. >> >> Well, the above need to be addressed for a start. >> >>> I would suggest any changes >>> converting to Maven brings affects mostly project structure, accessibility >>> and maintainability over the long term. >> >> The layout of SVN is not particularly important to me; that can be >> changed to suit Maven and the Ant file modified to suit. >> >> However, I do take issue with the proposition that converting to Maven >> necessarily reduces maintenance. >> >>>> >>>> Note also that the Ant build does some work that may be tricky to >>>> implement in Maven. >>>> For example, the documentation is built twice - once for web-site, and >>>> once for the dynamic help system. >>>> The build also creates a lot of different jars. >>>> My experience of multimodule Maven builds is that they can take a lot >>>> longer than Ant, and are tricky to get working correctly. >>>> >>>> I'm not saying that JMeter can't or won't use Maven for builds, but >>>> it's not going to be at all easy to implement and maintain. >>>> I know from my participation in Apache Commons that even simple >>>> projects can spend quite a lot of time on Maven issues. >>>> >>>> >>> It sounds like you have some valuable experience to draw upon. That's great! >> >> I'm the current release manager, and have been for several years. >> >>> As long as there is not a defacto no to experimenting using Maven then I >>> suggest to come up with a script first that does the conversion, and then >>> discuss if the end result tradeoffs make JMeter a better project or not (... >>> and if the changes the script applies should get committed). >> >> Rejigging the source files to fit in with Maven is a one-off effort, >> but before starting down this road, I think someone needs to show that >> JMeter will actually run OK when the jars are stored in a Maven repo. >> >> That should be possible to prove without needing to make any changes >> to the JMeter source layout. >> AIUI, it would just require copying the jars and basic POMs to a local >> repo, and creating a POM that depends on the JMeter jars. >> >> This work would not be wasted, as the POMs that are created will be >> needed later in the Mavenisation of JMeter (assuming the experiment is >> successful). >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
