jakarta-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Lynch <pe...@peterlynch.ca>
Subject Re: [JMeter] Convert to Maven based build?
Date Thu, 25 Nov 2010 17:54:50 GMT
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. 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message