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