jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Plugin market? (was: 3rd party jars - current and proposed)
Date Sat, 09 Apr 2016 18:18:05 GMT
On 9 April 2016 at 19:11, Philippe Mouawad <philippe.mouawad@gmail.com> wrote:
> 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.

They don't care so much about memory footprint as they are not benchmark utils.

> Standalone tool is again another tool so -1 for me.

That is not a valid argument.

> I prefer it in core tool.

-1.

There's no particular reason to have it in the 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.

Why, apart from not wanting a separate tool?

>
>>
>> > 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.

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

Mime
View raw message