jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Pokhilko <>
Subject Re: Plugin market? (was: 3rd party jars - current and proposed)
Date Tue, 12 Apr 2016 13:17:45 GMT
Yes, you can keep discussing the idea of plugins market as part of the
core, that's not an issue. Users would benefit from having it as part of
the core.

I'm not sure what you mean by "commercial plugin hoster". Most of the
plugins are downloaded from maven repositories. The plugins list is
downloaded from which is open source and non-commercial.

I've chosen the way of implementing it rather than discussing because
some things are so obvious that they need no discussion. It is still not
too late to share your feedback, because it is in beta testing stage.
For example, following your feedback I've removed the "BlazeMeter Set"...

Andrey Pokhilko

On 04/12/2016 03:53 PM, Philippe Mouawad wrote:
> On Saturday, April 9, 2016, Andrey Pokhilko <> wrote:
>> I speak about unknown element.
> ok
>> The plugins market needs no discussion, I'm 70% into implementing it.
> In my opinion it should have been discussed but you are free to implement
> it in "your" project, it appears it will rely on a commercial 3rd pArty as
> plugin hoster.
> We are of course free to discuss it within the project and choose a
> different way to do it.
> I still believe it must be in Core JMeter.
>> Andrey Pokhilko
>> On 04/09/2016 11:05 PM, Philippe Mouawad wrote:
>>> On Saturday, April 9, 2016, Andrey Pokhilko < <javascript:;>>
>> wrote:
>>>> Accepting bets on the discussion result... I'll better spend the time
>>>> writing code for "plugins market" than to have long discussions. Sorry,
>>>> that's my personal issues.
>>>> For me you got the feature idea right, message transferred, so what to
>>>> discuss :)?
>>> are you speaking about the plugin market or unknown element ?
>>> if first one, what can be discussed is the format and way of working.
>>> If unknown element, then it's true dev can start
>>>> Andrey Pokhilko
>>>> On 04/09/2016 10:21 PM, Philippe Mouawad wrote:
>>>>> what's the problem, let's discuss this in core
>>>>> On Saturday, April 9, 2016, Andrey Pokhilko < <javascript:;>
>> <javascript:;>>
>>>> wrote:
>>>>>> So you got the idea right. Unfortunately, this can't be done as
>>>>>> third-party plugin, it requires core change.
>>>>>> Andrey Pokhilko
>>>>>> On 04/09/2016 10:02 PM, Philippe Mouawad wrote:
>>>>>>> On Saturday, April 9, 2016, Andrey Pokhilko <
>> <javascript:;> <javascript:;>
>>>> <javascript:;>>
>>>>>> wrote:
>>>>>>>> In fact, I'm already working on "plugins repository" feature.
So it
>>>> will
>>>>>>>> be available soon.
>>>>>>>> What could be improved in JMeter regarding situation of unknown
>> plugin
>>>>>>>> in test plan is to still show the test plan, putting some
>>>> Class
>>>>>>>> Element" at the place of unknown classes. That would allow
>>>>>>>> these elements in UI which would be easier than monstrous
>>>> message
>>>>>>>> currently shown. Although I'd keep the message. Also the
plan with
>>>>>>>> "Unknown Element" present wouldn't be available for running.
>>>>>>>> another arguable idea from me, tangential to the subject
at hand, so
>>>>>>>> nevermind :).
>>>>>>>> I find this idea interesting.
>>>>>>> The ideal situation for me would be:
>>>>>>> - open the plan
>>>>>>> - Show as you propose unknown element for the missing class with
>> maybe
>>>>>> the
>>>>>>> stacktrace in the gui of this unknown element
>>>>>>> - when saving the plan, the missing class is not  changed so
>>>> initial
>>>>>>> plan is not corrupt
>>>>>>>> Andrey Pokhilko
>>>>>>>> On 04/09/2016 11:56 AM, sebb wrote:
>>>>>>>>> On 8 April 2016 at 22:40, Vladimir Sitnikov <
>>>>>> <javascript:;> <javascript:;>
>> <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.
>>>>>>>>>> For instance:
>>>>>>>>>> 1) Search & install plugins from within JMeter
>>>>>>>>> -1; that would add unnecessary classes to memory.
>>>>>>>>> However it could be stand-alone.
>>>>>>>>> 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.
>>>>>>>>>> 2) If loading a test plan that references not yet
>> plugins,
>>>>>>>>>> JMeter would be able to suggest installing the required
>>>>>>>>> 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?
>>>>>>>>> However it might be possible to improve the error messages
that are
>>>>>>>>> produced when test classes cannot be found.
>>>>>>>>>> Vladimir

View raw message