On Nov 25, 2010, at 2:29 PM, Peter Lin <wool...@gmail.com> wrote: > even though I haven't been active in jmeter in a while, I am still a > jmeter committer. >
Quantify "a while". I'm still a committee on various projects. Would I veto a change by someone with a defined need who shows initiative? No. If Peter Lynch has the itch, why not let him experiment? This place works on initiative, not a series of subjective objections to a tool he wishes to use. This place works only if people like yourself (like myself) get out of the way of people more active than ourselves. > > wrote: >> 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 <wool...@gmail.com> 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 <seb...@gmail.com> wrote: >>> >>>> On 25 November 2010 17:54, Peter Lynch <pe...@peterlynch.ca> wrote: >>>>> Hi sebb, >>>>> >>>>> On Thu, Nov 25, 2010 at 9:42 AM, sebb <seb...@gmail.com> wrote: >>>>> >>>>>> On 25 November 2010 14:18, Peter Lynch <ply...@apache.org> 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: dev-unsubscr...@jakarta.apache.org >>>> For additional commands, e-mail: dev-h...@jakarta.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >>> For additional commands, e-mail: dev-h...@jakarta.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >> For additional commands, e-mail: dev-h...@jakarta.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org > For additional commands, e-mail: dev-h...@jakarta.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
