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:41:35 GMT
On Saturday, April 9, 2016, sebb <sebbaz@gmail.com> wrote:

> On 9 April 2016 at 19:11, Philippe Mouawad <philippe.mouawad@gmail.com
> <javascript:;>> wrote:
> > On Saturday, April 9, 2016, sebb <sebbaz@gmail.com <javascript:;>>
> wrote:
> >
> >> On 8 April 2016 at 22:40, Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com <javascript:;>
> >> <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.
>
> They don't care so much about memory footprint as they are not benchmark
> utils.


it is not a problem, one can install and restart tool before load testing.
Anyway do you have numbers showing that classloading has important impact
knowing that classes are loaded on demand.
Things have hugely improved and currently permgen (if jdk7) is very low in
jmeter so we have space.


> > Standalone tool is again another tool so -1 for me.
>
> That is not a valid argument

it is valid in my opinion. Another tool means another docs, more things to
know while it can be in the help menu and easy to use.
It also means more work and packaging for us.



>
> > I prefer it in core tool.
>
> -1.
>
> There's no particular reason to have it in the core tool


it's only your opinion. Let's see what other think.
If we don't put it in core, then it mean a third party project will create
it and control the market and way to embed plugins.
I am against this.


>
> >
> >
> >>
> >> 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.
>
> Why, apart from not wanting a separate tool?


for ease of use, additional work it incurs for us.

>
> >
> >>
> >> > 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.
>
> Let's not discuss this at all further until after 3.0 otherwise it
> will delay the release.

of course this discussion is about 3.1 or 4.0

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


-- 
Cordialement.
Philippe Mouawad.

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