On Saturday, April 9, 2016, sebb <[email protected]> wrote: > On 8 April 2016 at 22:40, Vladimir Sitnikov <[email protected] > <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.
