jakarta-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim O'Brien <tobr...@discursive.com>
Subject Re: [JMeter] Convert to Maven based build?
Date Thu, 25 Nov 2010 19:56:53 GMT
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> 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


Mime
View raw message