jakarta-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Lin <wool...@gmail.com>
Subject Re: [JMeter] Convert to Maven based build?
Date Thu, 25 Nov 2010 23:58:35 GMT
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 <tobrien@discursive.com> wrote:
> On Nov 25, 2010, at 2:29 PM, Peter Lin <woolfel@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 <woolfel@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 <sebbaz@gmail.com> wrote:
>>>>> On 25 November 2010 17:54, Peter Lynch <peter@peterlynch.ca> wrote:
>>>>>> Hi sebb,
>>>>>> On Thu, Nov 25, 2010 at 9:42 AM, sebb <sebbaz@gmail.com> wrote:
>>>>>>> On 25 November 2010 14:18, Peter Lynch <plynch@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.
>>>>>>> Should be possible to maintain all SCM history if done properly.
>>>>>>> Note that changes of source layout will cause a (one-off) problem
>>>>>>> people who maintain private patches.
>>>>>>>> I have outlined some of the advantages this offers in this
>>>>>>>> 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
>>>>>> Java developers who want to contribute to the project. I'd like to
>>>>>> problems in JMeter source code by opening the project in any IDE
>>>>>> supports Maven project structures and know instantly how to run tests,
>>>>>> 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
>>>>>> 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
>>>>>>> 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
>>>>>>> implement in Maven.
>>>>>>> For example, the documentation is built twice - once for web-site,
>>>>>>> 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,
>>>>>>> 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
>>>>> 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

View raw message