[JMeter] Convert to Maven based build?

[Peter Lynch <pl...@apache.org>]

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.

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?

-Peter
<https://issues.apache.org/bugzilla/show_bug.cgi?id=50324>

Re: [JMeter] Convert to Maven based build?

[Peter Lin <wo...@gmail.com>]

honestly, I don't remember the last time I committed changes for
jmeter. it was a bug fix in something I wrote 5-6 years back.

I've contributed quite a bit of stuff to jmeter in the past and still
use it. For me, jmeter is a mature stable product that meets all of my
needs, so I haven't needed any new features the last 3-4 years.

I have no objections to stepping aside so that new people can get
involved. I just question the need to change from ANT to Maven.

JMeter is a stand alone app. From my own experience, people tend to
use maven to make it easier to deploy a webapp to a container, which
doesn't apply to jmeter. If the goal is to push jmeter jars to a maven
repository, there's no need to use maven.

simply create a task with ant that uploads the jars. JMeter's
structure is mature and works well. If someone can convince me of the
"actual" benefits of using maven with jmeter, I'll gladly eat crow and
vote for it. As I stated earlier, I hate maven and have a strong bias
from first hand experience. It's not like I came the conclusion
without using it.

I supported a complex project for over a year and half that used
maven. In practice, maintaining maven build often degenerates to a
full time job. This isn't some third hand story, I was the person
stuck with maintaining a maven build.

I have no desire to burden sebastian with maintaining maven build when
the current ant build works well and has basically zero maintenance
over head. Will moving to maven reduce maintenance cost below zero?

On Thu, Nov 25, 2010 at 3:44 PM, Tim O'Brien <to...@discursive.com> wrote:
> On Nov 25, 2010, at 2:29 PM, Peter Lin <wo...@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 <wo...@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 <se...@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 <se...@gmail.com> wrote:
>>>>>>
>>>>>>> On 25 November 2010 14:18, Peter Lynch <pl...@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-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org

Re: [JMeter] Convert to Maven based build?

[sebb <se...@gmail.com>]

On 26 November 2010 16:54, Phil Steitz <ph...@steitz.com> wrote:
> On Thu, Nov 25, 2010 at 4:29 PM, Rahul Akolkar <ra...@gmail.com>wrote:
>
>> On Thu, Nov 25, 2010 at 3:44 PM, Tim O'Brien <to...@discursive.com>
>> wrote:
>> > On Nov 25, 2010, at 2:29 PM, Peter Lin <wo...@gmail.com> wrote:
>> >
>> >> even though I haven't been active in jmeter in a while, I am still a
>> >> jmeter committer.
>> >>
>> >
>> > Quantify "a while".
>> >
>> <snip/>
>>
>> No need, we have archives for the curious.
>>
>>
>> > 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.
>> >
>> <snap/>
>>
>> All good above.
>>
>> Finally, the onus is on those who experiment to convince those who do
>> the work here that the proposed changes are then worthy.
>>
>> +1
>
> As one data point for a potential contributor, I will share the following.
> I have been lurking on this list for quite some time and intending to
> eventually propose some ideas/patches for enhancements.

We look forward to seeing these!

> Seeing this thread,
> i thought it would be a good idea to see how hard it was for me to get set
> up to build the code and run the tests.  The answer is it took me about 10
> minutes, which is frankly less time than most maven-built projects take to
> get going and *way less* than any nontrivial maven build.  I particularly
> like that there is a README as well as a building.html that clearly describe
> the simple steps necessary to get set up.  If you follow the directions to
> download the dependent jars and replace the Eclipse .classpath file with
> eclipse.classpath, Eclipse is fully set up.  I did not try to actually run
> anything from within Eclipse, as I find that is in general a bad idea for
> anything nontrivial;

Eclipse can easily be used for running and debugging JMeter, but
running some of the JUnit tests can be a bit of a pain as they need
the classpath to be set up correctly.

> but the nicely documented ant build.xml worked for me
> out of the box.  It was impressive to me that I did not have to fuss with
> any local property settings, given the amount of config that Jmeter and its
> tests use.
>
> [I did get the following test failure:
>
> [java] 1)
> runSerialTest(org.apache.jmeter.junit.JMeterTest)junit.framework.AssertionFailedError:
> serialization of org.apache.jmeter.functions.gui.FunctionHelper failed:
> java.io.NotSerializableException: com.apple.laf.AquaComboBoxUI
>
> Looks Apple-specific.   I am running
>  java version "1.6.0_22"
> Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)]

It does seem to be Apple-specific, though perhaps the field that holds
the GUI item could be made transient to avoid the problem.
The JMeter GUI does not need to be serialisable - only the test
element etc. that are required for running in client-server mode.
The FunctionHelper is GUI only, so could be dropped entirely from the
serialisation tests.

> Two of the ten minutes were spent fussing with Eclipse because I had
> replaced the classpath before downloading the jars.  Closing and reopening
> the project was not enough to get Eclipse to stop thinking the jars were
> "missing."  I had to recreate it after the jars were in place.  It might be
> better to change the instructions to remind people to download the jars
> before creating the Eclipse project.   I can submit a patch for that if
> others agree this is a good idea.

+1

> So I am personally finding it hard to believe that mavenizing the build is
> really going to make it easier for people to get involved with Jmeter.  If
> there are Jmeter artifacts of general usefulness, I think it would be a
> *good thing* to develop either Ant or Maven targets to get them published.
> That would be a much easier task than trying to get the full Jmeter build
> working in Maven.

+1

Seems to me to be a useful gain.

Is that something that can be easily done in Maven, using the current
directory layout and jar contents?

Patches welcome (via Bugzilla please).

> I agree strongly with Rahul and Peter Lin though that this decision belongs
> to them who do the work.

Thanks.

I'm not against Maven per se, but I have not seen it used on a project
with so many output jars and which makes assumptions about locations
of jars.

I may be wrong, but I can see no benefit to converting to a Maven
build, and there are several potential blockers which I (and others)
have already mentioned else-thread.

I can see no point in starting the process when it might not be
possible to achieve its goal.

So I don't intend personally to spend any time working on creating a
Maven build for JMeter.

> Phil
>
>
>
>
>
>> -Rahul
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org

Re: [JMeter] Convert to Maven based build?

[Peter Lin <wo...@gmail.com>]

well put. Far more elegant and objective than my rants!

I feel so scarred by maven that I will never recover :)

On Fri, Nov 26, 2010 at 11:54 AM, Phil Steitz <ph...@steitz.com> wrote:
> On Thu, Nov 25, 2010 at 4:29 PM, Rahul Akolkar <ra...@gmail.com>wrote:
>
>> On Thu, Nov 25, 2010 at 3:44 PM, Tim O'Brien <to...@discursive.com>
>> wrote:
>> > On Nov 25, 2010, at 2:29 PM, Peter Lin <wo...@gmail.com> wrote:
>> >
>> >> even though I haven't been active in jmeter in a while, I am still a
>> >> jmeter committer.
>> >>
>> >
>> > Quantify "a while".
>> >
>> <snip/>
>>
>> No need, we have archives for the curious.
>>
>>
>> > 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.
>> >
>> <snap/>
>>
>> All good above.
>>
>> Finally, the onus is on those who experiment to convince those who do
>> the work here that the proposed changes are then worthy.
>>
>> +1
>
> As one data point for a potential contributor, I will share the following.
> I have been lurking on this list for quite some time and intending to
> eventually propose some ideas/patches for enhancements.  Seeing this thread,
> i thought it would be a good idea to see how hard it was for me to get set
> up to build the code and run the tests.  The answer is it took me about 10
> minutes, which is frankly less time than most maven-built projects take to
> get going and *way less* than any nontrivial maven build.  I particularly
> like that there is a README as well as a building.html that clearly describe
> the simple steps necessary to get set up.  If you follow the directions to
> download the dependent jars and replace the Eclipse .classpath file with
> eclipse.classpath, Eclipse is fully set up.  I did not try to actually run
> anything from within Eclipse, as I find that is in general a bad idea for
> anything nontrivial; but the nicely documented ant build.xml worked for me
> out of the box.  It was impressive to me that I did not have to fuss with
> any local property settings, given the amount of config that Jmeter and its
> tests use.
>
> [I did get the following test failure:
>
> [java] 1)
> runSerialTest(org.apache.jmeter.junit.JMeterTest)junit.framework.AssertionFailedError:
> serialization of org.apache.jmeter.functions.gui.FunctionHelper failed:
> java.io.NotSerializableException: com.apple.laf.AquaComboBoxUI
>
> Looks Apple-specific.   I am running
>  java version "1.6.0_22"
> Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)]
>
> Two of the ten minutes were spent fussing with Eclipse because I had
> replaced the classpath before downloading the jars.  Closing and reopening
> the project was not enough to get Eclipse to stop thinking the jars were
> "missing."  I had to recreate it after the jars were in place.  It might be
> better to change the instructions to remind people to download the jars
> before creating the Eclipse project.   I can submit a patch for that if
> others agree this is a good idea.
>
> So I am personally finding it hard to believe that mavenizing the build is
> really going to make it easier for people to get involved with Jmeter.  If
> there are Jmeter artifacts of general usefulness, I think it would be a
> *good thing* to develop either Ant or Maven targets to get them published.
> That would be a much easier task than trying to get the full Jmeter build
> working in Maven.
>
> I agree strongly with Rahul and Peter Lin though that this decision belongs
> to them who do the work.
>
> Phil
>
>
>
>
>
>> -Rahul
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org

Re: [JMeter] Convert to Maven based build?

[Philippe Mouawad <p....@ubik-ingenierie.com>]

Hello,
As a casual and very modest contributor to the project (for now), I must say
I fully agree with Phil Steiz.
Setting up Eclipse project takes really 10 minutes and building was really
easy.
I don't think maven will bring enhancements in this domain but maybe more in
site generation for example and other classical reporting sites.

Regarding decisions about Maven, from my experience Maven2 seems now stable
and maybe going on Maven3 would be a little risky because in my Maven (1 &
2) experience,
build get stable after more than one minor versions.
In my opinion Ant should be kept besides maven, but this is my opinion of
course.

Regards
Philippe

On Fri, Nov 26, 2010 at 5:54 PM, Phil Steitz <ph...@steitz.com> wrote:

> On Thu, Nov 25, 2010 at 4:29 PM, Rahul Akolkar <rahul.akolkar@gmail.com
> >wrote:
>
> > On Thu, Nov 25, 2010 at 3:44 PM, Tim O'Brien <to...@discursive.com>
> > wrote:
> > > On Nov 25, 2010, at 2:29 PM, Peter Lin <wo...@gmail.com> wrote:
> > >
> > >> even though I haven't been active in jmeter in a while, I am still a
> > >> jmeter committer.
> > >>
> > >
> > > Quantify "a while".
> > >
> > <snip/>
> >
> > No need, we have archives for the curious.
> >
> >
> > > 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.
> > >
> > <snap/>
> >
> > All good above.
> >
> > Finally, the onus is on those who experiment to convince those who do
> > the work here that the proposed changes are then worthy.
> >
> > +1
>
> As one data point for a potential contributor, I will share the following.
> I have been lurking on this list for quite some time and intending to
> eventually propose some ideas/patches for enhancements.  Seeing this
> thread,
> i thought it would be a good idea to see how hard it was for me to get set
> up to build the code and run the tests.  The answer is it took me about 10
> minutes, which is frankly less time than most maven-built projects take to
> get going and *way less* than any nontrivial maven build.  I particularly
> like that there is a README as well as a building.html that clearly
> describe
> the simple steps necessary to get set up.  If you follow the directions to
> download the dependent jars and replace the Eclipse .classpath file with
> eclipse.classpath, Eclipse is fully set up.  I did not try to actually run
> anything from within Eclipse, as I find that is in general a bad idea for
> anything nontrivial; but the nicely documented ant build.xml worked for me
> out of the box.  It was impressive to me that I did not have to fuss with
> any local property settings, given the amount of config that Jmeter and its
> tests use.
>
> [I did get the following test failure:
>
> [java] 1)
>
> runSerialTest(org.apache.jmeter.junit.JMeterTest)junit.framework.AssertionFailedError:
> serialization of org.apache.jmeter.functions.gui.FunctionHelper failed:
> java.io.NotSerializableException: com.apple.laf.AquaComboBoxUI
>
> Looks Apple-specific.   I am running
>  java version "1.6.0_22"
> Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)]
>
> Two of the ten minutes were spent fussing with Eclipse because I had
> replaced the classpath before downloading the jars.  Closing and reopening
> the project was not enough to get Eclipse to stop thinking the jars were
> "missing."  I had to recreate it after the jars were in place.  It might be
> better to change the instructions to remind people to download the jars
> before creating the Eclipse project.   I can submit a patch for that if
> others agree this is a good idea.
>
> So I am personally finding it hard to believe that mavenizing the build is
> really going to make it easier for people to get involved with Jmeter.  If
> there are Jmeter artifacts of general usefulness, I think it would be a
> *good thing* to develop either Ant or Maven targets to get them published.
> That would be a much easier task than trying to get the full Jmeter build
> working in Maven.
>
> I agree strongly with Rahul and Peter Lin though that this decision belongs
> to them who do the work.
>
> Phil
>
>
>
>
>
> > -Rahul
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: dev-help@jakarta.apache.org
> >
> >
>



-- 
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie

Re: [JMeter] Convert to Maven based build?

[Phil Steitz <ph...@steitz.com>]

On Thu, Nov 25, 2010 at 4:29 PM, Rahul Akolkar <ra...@gmail.com>wrote:

> On Thu, Nov 25, 2010 at 3:44 PM, Tim O'Brien <to...@discursive.com>
> wrote:
> > On Nov 25, 2010, at 2:29 PM, Peter Lin <wo...@gmail.com> wrote:
> >
> >> even though I haven't been active in jmeter in a while, I am still a
> >> jmeter committer.
> >>
> >
> > Quantify "a while".
> >
> <snip/>
>
> No need, we have archives for the curious.
>
>
> > 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.
> >
> <snap/>
>
> All good above.
>
> Finally, the onus is on those who experiment to convince those who do
> the work here that the proposed changes are then worthy.
>
> +1

As one data point for a potential contributor, I will share the following.
I have been lurking on this list for quite some time and intending to
eventually propose some ideas/patches for enhancements.  Seeing this thread,
i thought it would be a good idea to see how hard it was for me to get set
up to build the code and run the tests.  The answer is it took me about 10
minutes, which is frankly less time than most maven-built projects take to
get going and *way less* than any nontrivial maven build.  I particularly
like that there is a README as well as a building.html that clearly describe
the simple steps necessary to get set up.  If you follow the directions to
download the dependent jars and replace the Eclipse .classpath file with
eclipse.classpath, Eclipse is fully set up.  I did not try to actually run
anything from within Eclipse, as I find that is in general a bad idea for
anything nontrivial; but the nicely documented ant build.xml worked for me
out of the box.  It was impressive to me that I did not have to fuss with
any local property settings, given the amount of config that Jmeter and its
tests use.

[I did get the following test failure:

[java] 1)
runSerialTest(org.apache.jmeter.junit.JMeterTest)junit.framework.AssertionFailedError:
serialization of org.apache.jmeter.functions.gui.FunctionHelper failed:
java.io.NotSerializableException: com.apple.laf.AquaComboBoxUI

Looks Apple-specific.   I am running
 java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)]

Two of the ten minutes were spent fussing with Eclipse because I had
replaced the classpath before downloading the jars.  Closing and reopening
the project was not enough to get Eclipse to stop thinking the jars were
"missing."  I had to recreate it after the jars were in place.  It might be
better to change the instructions to remind people to download the jars
before creating the Eclipse project.   I can submit a patch for that if
others agree this is a good idea.

So I am personally finding it hard to believe that mavenizing the build is
really going to make it easier for people to get involved with Jmeter.  If
there are Jmeter artifacts of general usefulness, I think it would be a
*good thing* to develop either Ant or Maven targets to get them published.
That would be a much easier task than trying to get the full Jmeter build
working in Maven.

I agree strongly with Rahul and Peter Lin though that this decision belongs
to them who do the work.

Phil





> -Rahul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>

Re: [JMeter] Convert to Maven based build?

[Rahul Akolkar <ra...@gmail.com>]

On Thu, Nov 25, 2010 at 3:44 PM, Tim O'Brien <to...@discursive.com> wrote:
> On Nov 25, 2010, at 2:29 PM, Peter Lin <wo...@gmail.com> wrote:
>
>> even though I haven't been active in jmeter in a while, I am still a
>> jmeter committer.
>>
>
> Quantify "a while".
>
<snip/>

No need, we have archives for the curious.


> 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.
>
<snap/>

All good above.

Finally, the onus is on those who experiment to convince those who do
the work here that the proposed changes are then worthy.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org

Re: [JMeter] Convert to Maven based build?

[Tim O'Brien <to...@discursive.com>]

On Nov 25, 2010, at 2:29 PM, Peter Lin <wo...@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 <wo...@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 <se...@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 <se...@gmail.com> wrote:
>>>>> 
>>>>>> On 25 November 2010 14:18, Peter Lynch <pl...@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-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org

Re: [JMeter] Convert to Maven based build?

[Peter Lin <wo...@gmail.com>]

On Fri, Nov 26, 2010 at 12:08 AM, Peter Lynch <pl...@apache.org> wrote:
> Peter Lin,
>
>
> On Thu, Nov 25, 2010 at 10:49 PM, Peter Lin <wo...@gmail.com> wrote:
>
>> so far I am not convinced of the benefits of changing to maven.
>>
>> my vote is still -1
>>
>> As I said before, my feeling is jmeter is mature and stable. JMeter
>> isn't missing any critical features and seb has done a phenominal job
>> of maintaining it.
>>
>> It's not like there's 10 critical features JMeter must have. Frankly,
>> I don't buy the argument that jmeter will die. Given JMeter's focus is
>>
>
> Obviously I did not suggest JMeter will die if it doesn't use Maven ?? Where
> in the world...
>
>
>> narrow, there's no point bloating it with lots of useless knobs and
>> buttons. I also don't buy the argument of building developer
>> community. JMeter's developer list has always been small even before I
>> joined. I attribute this to the focused nature of jmeter. JMeter
>> doesn't try to be the kitchen sink, butler, maid, dumb waiter, door
>> bell, race car and bus all rolled into one.
>>
>> What kind of improvement are you talking about? What kind of growth
>> are you talking about?
>>
>>
> I'm just suggesting that it is convenient to load a project's sources into a
> modern IDE and have the IDE instantly know how to build the project without
> setting up anything. That I can use previous knowledge of working on other
> projects and reuse it with this one. That it is useful for a project to
> share it's artifacts with others in a standard way. That someone who wants
> to contribute a patch or fix a bug or write a test has a lower barrier to
> entry.
>
> I've already stated other benefits in previous messages and in the bugzilla
> issue.
>
> Don't worry - I'm not launching JMeter Inc.

By modern IDE what do you mean? In eclipse atleast, maven plugin do
not work. Ant works out of the box in Eclipse and netbeans. Maven
seems to only work great if you use IntelliJ. I fully realize I have
baggage when it comes to maven and I clearly stated my bias. I'm
simply voicing my experience with maven so that others see the other
side of maven.

I leave the decision up to sebastian, since he is the only one that
really has any say.

> Is it really necessary to use terms like 'road to hell', describe some ideas
> as 'stupid', imply suffering and burdens.  Perhaps it may cause some people
> to ignore your experiences and opinions and focus instead on your generally
> poor demeanor. I'm not seeing how it helps your arguments.
>
> At the end of the day, I'm just looking to volunteer my time to add value to
> a project I use. I am not here to sell Maven like snake oil.
>
> I refuse to predict how great or horrible JMeter will become if it uses
> Maven - I'd rather spend time writing a conversion script to at least
> provide the option for factual evaluation.
>

it's selfish to not think of those who are maintaining it, simply
because you like maven and drank the koolaid. When I contribute to OSS
projects I simply follow the established procedures and submit a
patch. I don't try to change the existing setup. I just don't
understand why maven proponents push it on others.

I'm blunt and completely opinionated. I've seen several jakarta
projects convert from ant to maven and become a pain to build. Sorry
if my rants hurt your feelings, but maven tends to illicit that kind
of love it or hate it response.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org

Re: [JMeter] Convert to Maven based build?

[Peter Lynch <pl...@apache.org>]

Peter Lin,


On Thu, Nov 25, 2010 at 10:49 PM, Peter Lin <wo...@gmail.com> wrote:

> so far I am not convinced of the benefits of changing to maven.
>
> my vote is still -1
>
> As I said before, my feeling is jmeter is mature and stable. JMeter
> isn't missing any critical features and seb has done a phenominal job
> of maintaining it.
>
> It's not like there's 10 critical features JMeter must have. Frankly,
> I don't buy the argument that jmeter will die. Given JMeter's focus is
>

Obviously I did not suggest JMeter will die if it doesn't use Maven ?? Where
in the world...


> narrow, there's no point bloating it with lots of useless knobs and
> buttons. I also don't buy the argument of building developer
> community. JMeter's developer list has always been small even before I
> joined. I attribute this to the focused nature of jmeter. JMeter
> doesn't try to be the kitchen sink, butler, maid, dumb waiter, door
> bell, race car and bus all rolled into one.
>
> What kind of improvement are you talking about? What kind of growth
> are you talking about?
>
>
I'm just suggesting that it is convenient to load a project's sources into a
modern IDE and have the IDE instantly know how to build the project without
setting up anything. That I can use previous knowledge of working on other
projects and reuse it with this one. That it is useful for a project to
share it's artifacts with others in a standard way. That someone who wants
to contribute a patch or fix a bug or write a test has a lower barrier to
entry.

I've already stated other benefits in previous messages and in the bugzilla
issue.

Don't worry - I'm not launching JMeter Inc.

Performance tools have a nitch and will always be that way. There's no
> realistic way to drastically grow jmeter's user base. Even though the
> traffic on the mailing list doesn't show it, the user base is much
> larger. Before I joined jmeter, I thought the user base was small.
> Once I started hearing from users directly, it became apparent the
> user base is much larger. For example, I know aetna uses it across
> their enterprise and is officially recommended by their standards and
> practices group. That's a huge user base in just 1 health care
> company.
>
> I also know the university of connecticut uses jmeter as their
> standard testing tool.
>
> What's the difference between running ant vs build command? What's the
> cost vs time benefit for switching? I won't speak for sebastian, but
> my experience is that maven 1 & 2 aren't reliable. If sebastian is ok
> with the change, I'm ok with it. He is the one who has been actively
> maintaining it and he is the one who will have to suffer maven.
>
>
Is it really necessary to use terms like 'road to hell', describe some ideas
as 'stupid', imply suffering and burdens.  Perhaps it may cause some people
to ignore your experiences and opinions and focus instead on your generally
poor demeanor. I'm not seeing how it helps your arguments.

At the end of the day, I'm just looking to volunteer my time to add value to
a project I use. I am not here to sell Maven like snake oil.

I refuse to predict how great or horrible JMeter will become if it uses
Maven - I'd rather spend time writing a conversion script to at least
provide the option for factual evaluation.

Long after other developer leave, sebastian will probably be the one
> maintaining it. My suggestion is to think of sebastian and the burden
> you put on him. Don't arbitrarily change the build because you happen
> to love maven.
>
> On Thu, Nov 25, 2010 at 9:21 PM, Peter Lynch <pl...@apache.org> wrote:
> > Truthfully the main motivation for proposing to use Maven to build JMeter
> is
> > to increase the chances of getting more people involved in the project,
> to
> > fix bugs, to send patches and add features.
> >
> > Honestly do we expect the majority of potential developers to run for the
> > hills and the project to die if JMeter project is built with Maven?
> >
> >
> > On Thu, Nov 25, 2010 at 3:29 PM, Peter Lin <wo...@gmail.com> wrote:
> >
> >> even though I haven't been active in jmeter in a while, I am still a
> >> jmeter committer.
> >>
> >> quite honestly, I've seen maven work first hand.
> >>
> >> 1. the claim it reduces maintenance has not truth. My first hand
> >> experience is that it creates a much bigger burden.
> >>
> >>
> > Configuration management maintenance burden is relative to the frequency
> of
> > change within the project. If what JMeter delivers in terms of final
> > artifacts does not change, I don't expect maintaining a Maven build to
> > somehow require change for change sake.
> >
> > 2. changing the directory structure of jmeter to fit maven is wrong
> >> for several reasons. due to maven's "suggested structure" it's common
> >> to run into path length issues on windows platforms. When i was
> >> responsible for maintaining maven builds, we often had to rename unit
> >> tests because it exceeded 255 characters. Forcing everyone to use and
> >> build on linux or unix is not acceptable in my book.
> >>
> >>
> > Using an NTFS based Windows file system, UNC paths, path name components
> > (ie. a file name or directory name) under 260 characters and total path
> > length under ~32000 characters - there is no problem.
> >
> > Last I experienced a problem using Maven and long paths was with
> > JDK 1.5, Windows XP and a FAT filesystem. How many developers are
> building
> > JMeter on a FAT filesystem, I dunno but sounds like the chances of
> running
> > into this problem on a development environment nowadays is pretty slim.
> >
> >
> >
> >> 3. not everyone wants or cares to install maven.
> >>
> >>  Couldn't someone say that about any tool?
> >
> >
> >> 4. maven 1 and 2 are both slow
> >>
> >>
> > We cannot compare speed of the building JMeter using Maven because we
> have
> > no benchmark building it with Maven yet.
> >
> >  We create a script that converts to Maven project. Run the build actions
> > and understand the deployment process. Compare the build time it takes to
> do
> > common actions. Weigh any build time overhead with current build process
> and
> > all of the other benefits and go from there. Lets say the entire Maven
> build
> > takes 10 seconds longer (I have no data yet) - is it so bad that  all the
> > other benefits make it not worth it? If how to develop JMeter using IDEA,
> > Netbeans and Eclipse remains a black art compared to just importing a
> Maven
> > project into your IDE and go...is it worth it? Maybe...but lets at least
> > deal with facts at least. The first step to do that is to try it out.
> >
> >
> >> 5. maven repositories are notoriously unreliable. when maven
> >> repositories go down, maven builds fail until that repository comes
> >> back. A few years back codehaus went down due to hardware failure.
> >> people that relied on codehaus + maven ended up having build issues
> >>
> >>
> > The state of repository servers has changed quite a bit from a few years
> > ago.
> >
> > 6. maven 1 & 2 repositories are poorly designed and do not support
> >> versioning properly from first hand experience. Back when I maintained
> >> maven builds, we ended up creating multiple maven repositories
> >> internally so that we could support multiple releases.
> >>
> >>
> > I can say that using Maven 1 is a bad choice today if you have the
> > opportunity to use Maven 3. Since JMeter would be newly using Maven, I
> see
> > no reason not to use the latest version.
> >
> >
> > bottom line is, maven is poorly designed and not worth the hassle.
> >> Plenty of people find it works fine for them, and there's lots of
> >> people who love maven. I am not one of those people.
> >>
> >>
> >>
> > I'm looking to grow the JMeter community. I thought this was one way to
> help
> > do that.
> >
> > Really does this have to be a opinionated flame war? There are simple
> people
> > out there looking to volunteer to help a project grow and improve. I'm
> > offering to be one of them.
> >
> > -Peter
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>

Re: [JMeter] Convert to Maven based build?

[Peter Lin <wo...@gmail.com>]

so far I am not convinced of the benefits of changing to maven.

my vote is still -1

As I said before, my feeling is jmeter is mature and stable. JMeter
isn't missing any critical features and seb has done a phenominal job
of maintaining it.

It's not like there's 10 critical features JMeter must have. Frankly,
I don't buy the argument that jmeter will die. Given JMeter's focus is
narrow, there's no point bloating it with lots of useless knobs and
buttons. I also don't buy the argument of building developer
community. JMeter's developer list has always been small even before I
joined. I attribute this to the focused nature of jmeter. JMeter
doesn't try to be the kitchen sink, butler, maid, dumb waiter, door
bell, race car and bus all rolled into one.

What kind of improvement are you talking about? What kind of growth
are you talking about?

Performance tools have a nitch and will always be that way. There's no
realistic way to drastically grow jmeter's user base. Even though the
traffic on the mailing list doesn't show it, the user base is much
larger. Before I joined jmeter, I thought the user base was small.
Once I started hearing from users directly, it became apparent the
user base is much larger. For example, I know aetna uses it across
their enterprise and is officially recommended by their standards and
practices group. That's a huge user base in just 1 health care
company.

I also know the university of connecticut uses jmeter as their
standard testing tool.

What's the difference between running ant vs build command? What's the
cost vs time benefit for switching? I won't speak for sebastian, but
my experience is that maven 1 & 2 aren't reliable. If sebastian is ok
with the change, I'm ok with it. He is the one who has been actively
maintaining it and he is the one who will have to suffer maven.

Long after other developer leave, sebastian will probably be the one
maintaining it. My suggestion is to think of sebastian and the burden
you put on him. Don't arbitrarily change the build because you happen
to love maven.


On Thu, Nov 25, 2010 at 9:21 PM, Peter Lynch <pl...@apache.org> wrote:
> Truthfully the main motivation for proposing to use Maven to build JMeter is
> to increase the chances of getting more people involved in the project, to
> fix bugs, to send patches and add features.
>
> Honestly do we expect the majority of potential developers to run for the
> hills and the project to die if JMeter project is built with Maven?
>
>
> On Thu, Nov 25, 2010 at 3:29 PM, Peter Lin <wo...@gmail.com> wrote:
>
>> even though I haven't been active in jmeter in a while, I am still a
>> jmeter committer.
>>
>> quite honestly, I've seen maven work first hand.
>>
>> 1. the claim it reduces maintenance has not truth. My first hand
>> experience is that it creates a much bigger burden.
>>
>>
> Configuration management maintenance burden is relative to the frequency of
> change within the project. If what JMeter delivers in terms of final
> artifacts does not change, I don't expect maintaining a Maven build to
> somehow require change for change sake.
>
> 2. changing the directory structure of jmeter to fit maven is wrong
>> for several reasons. due to maven's "suggested structure" it's common
>> to run into path length issues on windows platforms. When i was
>> responsible for maintaining maven builds, we often had to rename unit
>> tests because it exceeded 255 characters. Forcing everyone to use and
>> build on linux or unix is not acceptable in my book.
>>
>>
> Using an NTFS based Windows file system, UNC paths, path name components
> (ie. a file name or directory name) under 260 characters and total path
> length under ~32000 characters - there is no problem.
>
> Last I experienced a problem using Maven and long paths was with
> JDK 1.5, Windows XP and a FAT filesystem. How many developers are building
> JMeter on a FAT filesystem, I dunno but sounds like the chances of running
> into this problem on a development environment nowadays is pretty slim.
>
>
>
>> 3. not everyone wants or cares to install maven.
>>
>>  Couldn't someone say that about any tool?
>
>
>> 4. maven 1 and 2 are both slow
>>
>>
> We cannot compare speed of the building JMeter using Maven because we have
> no benchmark building it with Maven yet.
>
>  We create a script that converts to Maven project. Run the build actions
> and understand the deployment process. Compare the build time it takes to do
> common actions. Weigh any build time overhead with current build process and
> all of the other benefits and go from there. Lets say the entire Maven build
> takes 10 seconds longer (I have no data yet) - is it so bad that  all the
> other benefits make it not worth it? If how to develop JMeter using IDEA,
> Netbeans and Eclipse remains a black art compared to just importing a Maven
> project into your IDE and go...is it worth it? Maybe...but lets at least
> deal with facts at least. The first step to do that is to try it out.
>
>
>> 5. maven repositories are notoriously unreliable. when maven
>> repositories go down, maven builds fail until that repository comes
>> back. A few years back codehaus went down due to hardware failure.
>> people that relied on codehaus + maven ended up having build issues
>>
>>
> The state of repository servers has changed quite a bit from a few years
> ago.
>
> 6. maven 1 & 2 repositories are poorly designed and do not support
>> versioning properly from first hand experience. Back when I maintained
>> maven builds, we ended up creating multiple maven repositories
>> internally so that we could support multiple releases.
>>
>>
> I can say that using Maven 1 is a bad choice today if you have the
> opportunity to use Maven 3. Since JMeter would be newly using Maven, I see
> no reason not to use the latest version.
>
>
> bottom line is, maven is poorly designed and not worth the hassle.
>> Plenty of people find it works fine for them, and there's lots of
>> people who love maven. I am not one of those people.
>>
>>
>>
> I'm looking to grow the JMeter community. I thought this was one way to help
> do that.
>
> Really does this have to be a opinionated flame war? There are simple people
> out there looking to volunteer to help a project grow and improve. I'm
> offering to be one of them.
>
> -Peter
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org

Re: [JMeter] Convert to Maven based build?

[Peter Lynch <pl...@apache.org>]

Truthfully the main motivation for proposing to use Maven to build JMeter is
to increase the chances of getting more people involved in the project, to
fix bugs, to send patches and add features.

Honestly do we expect the majority of potential developers to run for the
hills and the project to die if JMeter project is built with Maven?


On Thu, Nov 25, 2010 at 3:29 PM, Peter Lin <wo...@gmail.com> wrote:

> even though I haven't been active in jmeter in a while, I am still a
> jmeter committer.
>
> quite honestly, I've seen maven work first hand.
>
> 1. the claim it reduces maintenance has not truth. My first hand
> experience is that it creates a much bigger burden.
>
>
Configuration management maintenance burden is relative to the frequency of
change within the project. If what JMeter delivers in terms of final
artifacts does not change, I don't expect maintaining a Maven build to
somehow require change for change sake.

2. changing the directory structure of jmeter to fit maven is wrong
> for several reasons. due to maven's "suggested structure" it's common
> to run into path length issues on windows platforms. When i was
> responsible for maintaining maven builds, we often had to rename unit
> tests because it exceeded 255 characters. Forcing everyone to use and
> build on linux or unix is not acceptable in my book.
>
>
Using an NTFS based Windows file system, UNC paths, path name components
(ie. a file name or directory name) under 260 characters and total path
length under ~32000 characters - there is no problem.

Last I experienced a problem using Maven and long paths was with
JDK 1.5, Windows XP and a FAT filesystem. How many developers are building
JMeter on a FAT filesystem, I dunno but sounds like the chances of running
into this problem on a development environment nowadays is pretty slim.



> 3. not everyone wants or cares to install maven.
>
>  Couldn't someone say that about any tool?


> 4. maven 1 and 2 are both slow
>
>
We cannot compare speed of the building JMeter using Maven because we have
no benchmark building it with Maven yet.

 We create a script that converts to Maven project. Run the build actions
and understand the deployment process. Compare the build time it takes to do
common actions. Weigh any build time overhead with current build process and
all of the other benefits and go from there. Lets say the entire Maven build
takes 10 seconds longer (I have no data yet) - is it so bad that  all the
other benefits make it not worth it? If how to develop JMeter using IDEA,
Netbeans and Eclipse remains a black art compared to just importing a Maven
project into your IDE and go...is it worth it? Maybe...but lets at least
deal with facts at least. The first step to do that is to try it out.


> 5. maven repositories are notoriously unreliable. when maven
> repositories go down, maven builds fail until that repository comes
> back. A few years back codehaus went down due to hardware failure.
> people that relied on codehaus + maven ended up having build issues
>
>
The state of repository servers has changed quite a bit from a few years
ago.

6. maven 1 & 2 repositories are poorly designed and do not support
> versioning properly from first hand experience. Back when I maintained
> maven builds, we ended up creating multiple maven repositories
> internally so that we could support multiple releases.
>
>
I can say that using Maven 1 is a bad choice today if you have the
opportunity to use Maven 3. Since JMeter would be newly using Maven, I see
no reason not to use the latest version.


bottom line is, maven is poorly designed and not worth the hassle.
> Plenty of people find it works fine for them, and there's lots of
> people who love maven. I am not one of those people.
>
>
>
I'm looking to grow the JMeter community. I thought this was one way to help
do that.

Really does this have to be a opinionated flame war? There are simple people
out there looking to volunteer to help a project grow and improve. I'm
offering to be one of them.

-Peter


> On Thu, Nov 25, 2010 at 2:56 PM, Tim O'Brien <to...@discursive.com>
> 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 <wo...@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 <se...@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 <se...@gmail.com> wrote:
> >>>>
> >>>>> On 25 November 2010 14:18, Peter Lynch <pl...@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-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail: dev-help@jakarta.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: dev-help@jakarta.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>

Re: [JMeter] Convert to Maven based build?

[Peter Lin <wo...@gmail.com>]

even though I haven't been active in jmeter in a while, I am still a
jmeter committer.

quite honestly, I've seen maven work first hand.

1. the claim it reduces maintenance has not truth. My first hand
experience is that it creates a much bigger burden.

2. changing the directory structure of jmeter to fit maven is wrong
for several reasons. due to maven's "suggested structure" it's common
to run into path length issues on windows platforms. When i was
responsible for maintaining maven builds, we often had to rename unit
tests because it exceeded 255 characters. Forcing everyone to use and
build on linux or unix is not acceptable in my book.

3. not everyone wants or cares to install maven.

4. maven 1 and 2 are both slow

5. maven repositories are notoriously unreliable. when maven
repositories go down, maven builds fail until that repository comes
back. A few years back codehaus went down due to hardware failure.
people that relied on codehaus + maven ended up having build issues

6. maven 1 & 2 repositories are poorly designed and do not support
versioning properly from first hand experience. Back when I maintained
maven builds, we ended up creating multiple maven repositories
internally so that we could support multiple releases.

bottom line is, maven is poorly designed and not worth the hassle.
Plenty of people find it works fine for them, and there's lots of
people who love maven. I am not one of those people.



On Thu, Nov 25, 2010 at 2:56 PM, Tim O'Brien <to...@discursive.com> 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 <wo...@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 <se...@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 <se...@gmail.com> wrote:
>>>>
>>>>> On 25 November 2010 14:18, Peter Lynch <pl...@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-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org

Re: [JMeter] Convert to Maven based build?

[Tim O'Brien <to...@discursive.com>]

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 <wo...@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 <se...@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 <se...@gmail.com> wrote:
>>> 
>>>> On 25 November 2010 14:18, Peter Lynch <pl...@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-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org

Re: [JMeter] Convert to Maven based build?

[Peter Lin <wo...@gmail.com>]

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 <se...@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 <se...@gmail.com> wrote:
>> 
>>> On 25 November 2010 14:18, Peter Lynch <pl...@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-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org

Re: [JMeter] Convert to Maven based build?

[sebb <se...@gmail.com>]

On 25 November 2010 17:54, Peter Lynch <pe...@peterlynch.ca> wrote:
> Hi sebb,
>
> On Thu, Nov 25, 2010 at 9:42 AM, sebb <se...@gmail.com> wrote:
>
>> On 25 November 2010 14:18, Peter Lynch <pl...@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-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org

Re: [JMeter] Convert to Maven based build?

[Rahul Akolkar <ra...@gmail.com>]

I've accepted the message below from the moderation queue, but please
subscribe using your .ca address if you intend to keep posting to this
list from it.

-Rahul


On Thu, Nov 25, 2010 at 12:54 PM, Peter Lynch <pe...@peterlynch.ca> wrote:
> Hi sebb,
>
> On Thu, Nov 25, 2010 at 9:42 AM, sebb <se...@gmail.com> wrote:
>
>> On 25 November 2010 14:18, Peter Lynch <pl...@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. It may turn out
> that during the conversion process there is some roadblock that would
> prevent Maven being useful - but I doubt it. I would suggest any changes
> converting to Maven brings affects mostly project structure, accessibility
> and maintainability over the long term.
>
>
>>
>> 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!
>
> 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).
>
>
>
>> > -Peter
>> > <https://issues.apache.org/bugzilla/show_bug.cgi?id=50324>
>> >
>>
>
> --
> Peter Lynch
> http://blog.peterlynch.ca
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org

Re: [JMeter] Convert to Maven based build?

[Peter Lynch <pe...@peterlynch.ca>]

Hi sebb,

On Thu, Nov 25, 2010 at 9:42 AM, sebb <se...@gmail.com> wrote:

> On 25 November 2010 14:18, Peter Lynch <pl...@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. It may turn out
that during the conversion process there is some roadblock that would
prevent Maven being useful - but I doubt it. I would suggest any changes
converting to Maven brings affects mostly project structure, accessibility
and maintainability over the long term.


>
> 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!

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).



> > -Peter
> > <https://issues.apache.org/bugzilla/show_bug.cgi?id=50324>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>


-- 
Peter Lynch
http://blog.peterlynch.ca

Re: [JMeter] Convert to Maven based build?

[sebb <se...@gmail.com>]

On 25 November 2010 14:18, Peter Lynch <pl...@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?

Is it just so that JMeter jars can be uploaded to Maven Central?
If so, then there are simpler ways to achieve this.

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.

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.

> -Peter
> <https://issues.apache.org/bugzilla/show_bug.cgi?id=50324>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org