You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by sebb <se...@gmail.com> on 2016/04/09 10:56:04 UTC
Plugin market? (was: 3rd party jars - current and proposed)
On 8 April 2016 at 22:40, Vladimir Sitnikov <si...@gmail.com> 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 UI
-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 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?
However it might be possible to improve the error messages that are
produced when test classes cannot be found.
> Vladimir
Re: Plugin market? (was: 3rd party jars - current and proposed)
Posted by Philippe Mouawad <ph...@gmail.com>.
On Saturday, April 9, 2016, sebb <se...@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.
Re: Plugin market? (was: 3rd party jars - current and proposed)
Posted by sebb <se...@gmail.com>.
On 9 April 2016 at 19:11, Philippe Mouawad <ph...@gmail.com> wrote:
> On Saturday, April 9, 2016, sebb <se...@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.
Re: Plugin market? (was: 3rd party jars - current and proposed)
Posted by Philippe Mouawad <ph...@gmail.com>.
On Saturday, April 9, 2016, sebb <se...@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.
Re: Plugin market? (was: 3rd party jars - current and proposed)
Posted by Vladimir Sitnikov <si...@gmail.com>.
Philippe>I know work on 3.0 is finished and milamber proposed to
be rm right ?
Sorry, I must have missed that.
Philippe>But if you want we can discuss later after 3.0
Anytime works for me provided it does not delay 3.0.
sebb>They don't care so much about memory footprint as they are not
benchmark utils.
I agree it is important to keep memory footprint sane, however I'm
sure it can easily be done negligible.
sebb> There's no particular reason to have it in the core tool.
You have no second chance to make the first impression.
Suppose a new user installs JMeter. How would (s)he know which plugins
are required?
Let me exaggerate to make the point more clear: "in order to install
JMeter you need to download ant, then perform svn checkout ..., then
ant download_jars, then ant install, then find JMeter Plugins in
Google, ..."
Not having out-of-the-box market makes first-time experience not that smooth.
Remember that typical JMeter users are not java programmers. They have
no-to-very little idea what the jar file is.
Of course, I've made that up, however I do believe that vision is right.
Having thought a bit more, I think jmeter-wrapper (named after "gradle
wrapper", though not using gradle in any way) script might be useful
as well (to have reproducible environment).
I mean the following:
1) User (or JMeter) creates a file with text description of exact
JMeter version and the versions of installed plugins. For instance:
jmeter-installation-versions.xml
2) If someone wants to reproduce exactly the same JMeter installation,
he picks that jmeter-installation-versions.xml
and executes "./jmeter-wrapper".
3) The wrapper script downloads proper JMeter and plugins versions.
Vladimir
Re: Plugin market? (was: 3rd party jars - current and proposed)
Posted by Andrey Pokhilko <ap...@ya.ru>.
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 jmeter-plugins.org 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 <ap...@ya.ru> 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 <apc4@ya.ru <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 <apc4@ya.ru <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 <apc4@ya.ru
>> <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 "Unknown
>>>> Class
>>>>>>>> Element" at the place of unknown classes. That would allow reviewing
>>>>>>>> these elements in UI which would be easier than monstrous error
>>>> message
>>>>>>>> currently shown. Although I'd keep the message. Also the plan with
>>>>>>>> "Unknown Element" present wouldn't be available for running. Well,
>>>>>>>> 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 the
>>>> 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 <
>>>>>> sitnikov.vladimir@gmail.com <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 UI
>>>>>>>>> -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 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?
>>>>>>>>>
>>>>>>>>> However it might be possible to improve the error messages that are
>>>>>>>>> produced when test classes cannot be found.
>>>>>>>>>
>>>>>>>>>> Vladimir
>>
Re: Plugin market? (was: 3rd party jars - current and proposed)
Posted by Philippe Mouawad <ph...@gmail.com>.
On Saturday, April 9, 2016, Andrey Pokhilko <ap...@ya.ru> 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 <apc4@ya.ru <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 <apc4@ya.ru <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 <apc4@ya.ru
> <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 "Unknown
> >> Class
> >>>>>> Element" at the place of unknown classes. That would allow reviewing
> >>>>>> these elements in UI which would be easier than monstrous error
> >> message
> >>>>>> currently shown. Although I'd keep the message. Also the plan with
> >>>>>> "Unknown Element" present wouldn't be available for running. Well,
> >>>>>> 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 the
> >> 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 <
> >>>> sitnikov.vladimir@gmail.com <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 UI
> >>>>>>> -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 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?
> >>>>>>>
> >>>>>>> However it might be possible to improve the error messages that are
> >>>>>>> produced when test classes cannot be found.
> >>>>>>>
> >>>>>>>> Vladimir
> >>
>
>
--
Cordialement.
Philippe Mouawad.
Re: Plugin market? (was: 3rd party jars - current and proposed)
Posted by Andrey Pokhilko <ap...@ya.ru>.
I speak about unknown element.
The plugins market needs no discussion, I'm 70% into implementing it.
Andrey Pokhilko
On 04/09/2016 11:05 PM, Philippe Mouawad wrote:
> On Saturday, April 9, 2016, Andrey Pokhilko <ap...@ya.ru> 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 <apc4@ya.ru <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 <apc4@ya.ru <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 "Unknown
>> Class
>>>>>> Element" at the place of unknown classes. That would allow reviewing
>>>>>> these elements in UI which would be easier than monstrous error
>> message
>>>>>> currently shown. Although I'd keep the message. Also the plan with
>>>>>> "Unknown Element" present wouldn't be available for running. Well,
>>>>>> 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 the
>> 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 <
>>>> sitnikov.vladimir@gmail.com <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 UI
>>>>>>> -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 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?
>>>>>>>
>>>>>>> However it might be possible to improve the error messages that are
>>>>>>> produced when test classes cannot be found.
>>>>>>>
>>>>>>>> Vladimir
>>
Re: Plugin market? (was: 3rd party jars - current and proposed)
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 9. April 2016 22:26:35 MESZ, schrieb Milamber <mi...@apache.org>:
>
>
>On 09/04/2016 21:12, Philippe Mouawad wrote:
>> On Saturday, April 9, 2016, Vladimir Sitnikov
><si...@gmail.com>
>> wrote:
>>
>>> Philippe>are you speaking about the plugin market or unknown element
>?
>>>
>>> I like the idea of sebb: release 3.0, then discuss other subjects of
>>> matter.
>>>
>>> Does that work?
>>
>> yes but as far as I know work on 3.0 is finished and milamber
>proposed to
>> be rm right ?
>
>Yes, if the PMC team are ok to start the RC1 process for 3.0, I can act
>
>as RM.
>
>I think too that the 3.0 is ready to release.
I think it is ready, too.
Felix
>
>
>> So we can discuss future subjects.
>>
>> But if you want we can discuss later after 3.0
>>
>>> Vladimir
>>>
>>
Re: Plugin market? (was: 3rd party jars - current and proposed)
Posted by Milamber <mi...@apache.org>.
On 09/04/2016 21:12, Philippe Mouawad wrote:
> On Saturday, April 9, 2016, Vladimir Sitnikov <si...@gmail.com>
> wrote:
>
>> Philippe>are you speaking about the plugin market or unknown element ?
>>
>> I like the idea of sebb: release 3.0, then discuss other subjects of
>> matter.
>>
>> Does that work?
>
> yes but as far as I know work on 3.0 is finished and milamber proposed to
> be rm right ?
Yes, if the PMC team are ok to start the RC1 process for 3.0, I can act
as RM.
I think too that the 3.0 is ready to release.
> So we can discuss future subjects.
>
> But if you want we can discuss later after 3.0
>
>> Vladimir
>>
>
Re: Plugin market? (was: 3rd party jars - current and proposed)
Posted by Philippe Mouawad <ph...@gmail.com>.
On Saturday, April 9, 2016, Vladimir Sitnikov <si...@gmail.com>
wrote:
> Philippe>are you speaking about the plugin market or unknown element ?
>
> I like the idea of sebb: release 3.0, then discuss other subjects of
> matter.
>
> Does that work?
yes but as far as I know work on 3.0 is finished and milamber proposed to
be rm right ?
So we can discuss future subjects.
But if you want we can discuss later after 3.0
> Vladimir
>
--
Cordialement.
Philippe Mouawad.
Re: Plugin market? (was: 3rd party jars - current and proposed)
Posted by Vladimir Sitnikov <si...@gmail.com>.
Philippe>are you speaking about the plugin market or unknown element ?
I like the idea of sebb: release 3.0, then discuss other subjects of matter.
Does that work?
Vladimir
Re: Plugin market? (was: 3rd party jars - current and proposed)
Posted by Philippe Mouawad <ph...@gmail.com>.
On Saturday, April 9, 2016, Andrey Pokhilko <ap...@ya.ru> 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 <apc4@ya.ru <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 <apc4@ya.ru <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 "Unknown
> Class
> >>>> Element" at the place of unknown classes. That would allow reviewing
> >>>> these elements in UI which would be easier than monstrous error
> message
> >>>> currently shown. Although I'd keep the message. Also the plan with
> >>>> "Unknown Element" present wouldn't be available for running. Well,
> >>>> 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 the
> 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 <
> >> sitnikov.vladimir@gmail.com <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 UI
> >>>>> -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 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?
> >>>>>
> >>>>> However it might be possible to improve the error messages that are
> >>>>> produced when test classes cannot be found.
> >>>>>
> >>>>>> Vladimir
> >>
>
>
--
Cordialement.
Philippe Mouawad.
Re: Plugin market? (was: 3rd party jars - current and proposed)
Posted by Andrey Pokhilko <ap...@ya.ru>.
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 :)?
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 <ap...@ya.ru> 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 <apc4@ya.ru <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 "Unknown Class
>>>> Element" at the place of unknown classes. That would allow reviewing
>>>> these elements in UI which would be easier than monstrous error message
>>>> currently shown. Although I'd keep the message. Also the plan with
>>>> "Unknown Element" present wouldn't be available for running. Well,
>>>> 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 the 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 <
>> 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.
>>>>>
>>>>>> For instance:
>>>>>> 1) Search & install plugins from within JMeter UI
>>>>> -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 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?
>>>>>
>>>>> However it might be possible to improve the error messages that are
>>>>> produced when test classes cannot be found.
>>>>>
>>>>>> Vladimir
>>
Re: Plugin market? (was: 3rd party jars - current and proposed)
Posted by Philippe Mouawad <ph...@gmail.com>.
what's the problem, let's discuss this in core
On Saturday, April 9, 2016, Andrey Pokhilko <ap...@ya.ru> 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 <apc4@ya.ru <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 "Unknown Class
> >> Element" at the place of unknown classes. That would allow reviewing
> >> these elements in UI which would be easier than monstrous error message
> >> currently shown. Although I'd keep the message. Also the plan with
> >> "Unknown Element" present wouldn't be available for running. Well,
> >> 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 the 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 <
> 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.
> >>>
> >>>> For instance:
> >>>> 1) Search & install plugins from within JMeter UI
> >>> -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 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?
> >>>
> >>> However it might be possible to improve the error messages that are
> >>> produced when test classes cannot be found.
> >>>
> >>>> Vladimir
> >>
>
>
--
Cordialement.
Philippe Mouawad.
Re: Plugin market? (was: 3rd party jars - current and proposed)
Posted by Andrey Pokhilko <ap...@ya.ru>.
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 <ap...@ya.ru> 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 "Unknown Class
>> Element" at the place of unknown classes. That would allow reviewing
>> these elements in UI which would be easier than monstrous error message
>> currently shown. Although I'd keep the message. Also the plan with
>> "Unknown Element" present wouldn't be available for running. Well,
>> 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 the 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 <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.
>>>
>>>> For instance:
>>>> 1) Search & install plugins from within JMeter UI
>>> -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 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?
>>>
>>> However it might be possible to improve the error messages that are
>>> produced when test classes cannot be found.
>>>
>>>> Vladimir
>>
Re: Plugin market? (was: 3rd party jars - current and proposed)
Posted by Philippe Mouawad <ph...@gmail.com>.
On Saturday, April 9, 2016, Andrey Pokhilko <ap...@ya.ru> 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 "Unknown Class
> Element" at the place of unknown classes. That would allow reviewing
> these elements in UI which would be easier than monstrous error message
> currently shown. Although I'd keep the message. Also the plan with
> "Unknown Element" present wouldn't be available for running. Well,
> 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 the 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 <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.
> >
> >> For instance:
> >> 1) Search & install plugins from within JMeter UI
> > -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 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?
> >
> > However it might be possible to improve the error messages that are
> > produced when test classes cannot be found.
> >
> >> Vladimir
>
>
--
Cordialement.
Philippe Mouawad.
Re: Plugin market? (was: 3rd party jars - current and proposed)
Posted by Andrey Pokhilko <ap...@ya.ru>.
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 "Unknown Class
Element" at the place of unknown classes. That would allow reviewing
these elements in UI which would be easier than monstrous error message
currently shown. Although I'd keep the message. Also the plan with
"Unknown Element" present wouldn't be available for running. Well,
another arguable idea from me, tangential to the subject at hand, so
nevermind :).
Andrey Pokhilko
On 04/09/2016 11:56 AM, sebb wrote:
> On 8 April 2016 at 22:40, Vladimir Sitnikov <si...@gmail.com> 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 UI
> -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 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?
>
> However it might be possible to improve the error messages that are
> produced when test classes cannot be found.
>
>> Vladimir