jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
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 <sebbaz@gmail.com> wrote:

> On 8 April 2016 at 22:40, Vladimir Sitnikov <sitnikov.vladimir@gmail.com
> <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
>


-- 
Cordialement.
Philippe Mouawad.

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