jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <>
Subject Re: Plugin market? (was: 3rd party jars - current and proposed)
Date Sat, 09 Apr 2016 18:11:59 GMT
On Saturday, April 9, 2016, sebb <> wrote:

> On 8 April 2016 at 22:40, Vladimir Sitnikov <
> <javascript:;>> wrote:
> > Philippe> The idea was interesting because it makes things rather simple.
> >
> > What if we take a step back and consider some kind of "JMeter Plugin
> Market"?
> This is tangential to the subject at hand.

I find the idea great.
Eclise, jira, jenkins do that
But it is some piece of work, yes.

I think the client part should be defined by the core project to allow :
- local installation
- installation from remote servers

This will enable a more independant mechanism.

> > For instance:
> > 1) Search & install plugins from within JMeter UI
> -1; that would add unnecessary classes to memory.
> However it could be stand-alone.

Eclipse does it, jconsole also.
The additional classes footprint is imho not a valid counter argument.
Standalone tool is again another tool so -1 for me.
I prefer it in core tool.

> Though I'm not sure how much work it would save compared with the
> effort of creating and maintaining it. That sounds like a good 3rd
> party project; it seems OT for JMeter.

As I wrote before client part should be Core.

> > 2) If loading a test plan that references not yet installed plugins,
> > JMeter would be able to suggest installing the required ones
> JMeter only knows what classes the test plan cannot find.
> Who is going to maintain the database of plugin locations and their
> classes?
> Who is going to vet the plugins?

Let's think about a mechanism before stopping everything.

> However it might be possible to improve the error messages that are
> produced when test classes cannot be found.
> > Vladimir

Philippe Mouawad.

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