Am Montag, den 04.04.2016, 19:44 +0300 schrieb Andrey Pokhilko: > That makes sense. > > The question of "when add it" is separate from "if add it". If your > objection is only for "when" then we have a time to discuss the idea. > > Actually, I see an opportunity for this mechanism to actually slurp in > some of JMeter core plugin sets, like "mongodb", "mail" or "ftp" or > others. The way of "put JMeter functionality into same bucket with its > dependencies" might allow to isolate JARs that are rarely used and allow > to not load them in certain cases. This would crystallize core libraries > from functionality libraries, opening door to manage it. > > I understand that JMeter's core is "time-proven", but time changes and > world evolves around us. At the time the core loading pieces were > created, there were not as many plugins and vendors. And now there are > tens of them. Makes sense to evolve the tool to reflect new realities. > > sebb, can you review the code and say your opinion if it is truly > non-intrusive? > > Others, can you express your opinion on this feature/idea? Milamber, Felix?
I don't want to include it in 3.0, but I think a standard way to include thirdparty libraries apart from editing jmeter.properties is a nice feature to have. Felix > > Andrey Pokhilko > > On 04/04/2016 07:30 PM, sebb wrote: > > I am -1 for adding this in 3.0 > > > > I don't think there's enough time to consider whether it truly is > > non-intrusive or even whether it is the best solution. > > > > It took quite a while to sort out JMeter class paths to ensure that > > classes are only loaded when necessary. > > The more jars there are in core JMeter, the more this becomes > > important to minimise memory consumption. > > > > It may turn out to be OK, but this is not something that can be added > > at the last minute. > > > > > > On 4 April 2016 at 17:19, Andrey Pokhilko <a...@ya.ru> wrote: > >> How does it help to remove complexity from user? Is there a way to > >> seamlessly put bunch of files taken from plugin vendor and get them > >> loaded by JMeter? It's not convenient way to require users to edit > >> properties files every time they install plugins. > >> > >> Until now there was kinda "seamless" way of dropping JAR files into > >> "lib" and "lib/ext", but it mixes core JARs with third-party JARs, > >> making it difficult to solve possible conflicts. > >> > >> Why you object against some "new" mechanism in JMeter? Does it do any harm? > >> > >> Andrey Pokhilko > >> > >> On 04/04/2016 07:10 PM, sebb wrote: > >>> On 4 April 2016 at 14:34, Andrey Pokhilko <a...@ya.ru> wrote: > >>>> Due to non-intrusive nature of the change, may I commit the change to > >>>> become part of 3.0 before we got first RC? > >>>> > >>>> Any objections? > >>> Yes, I object. > >>> > >>> Unless I am misunderstanding something there is *already* a mechanism > >>> for handling external jars and classes which is much more flexible. > >>> > >>> That is, the user.classpath property and the plugin_dependency_paths > >>> property. > >>> > >>>> Andrey Pokhilko > >>>> > >>>> On 04/04/2016 03:36 PM, Philippe Mouawad wrote: > >>>>> On Monday, April 4, 2016, Andrey Pokhilko <a...@ya.ru > >>>>> <javascript:_e(%7B%7D,'cvml','a...@ya.ru');>> wrote: > >>>>> > >>>>>> I've prepared a pull request, everyone can try playing with it: > >>>>>> https://github.com/apache/jmeter/pull/181/files > >>>>>> > >>>>>> The way it is done do not break any of existing jmeter class search > >>>>>> functionalities. In fact, it just extends the list of search paths > >>>>>> (thanks for hint, Philippe). So just more places searched for classes, > >>>>>> nothing more. > >>>>>> > >>>>>> Please review the pull request and tell me what you think. Including if > >>>>>> it is safe to put it into 3.0 or not (it's my humble request, waiting > >>>>>> another year for next JMeter release is a bit too much :) > >>>>> It is a 3.0 so it took a bit more time. > >>>>> I think in future we should release more often (2/3 times a year unless > >>>>> there's no need). > >>>>> > >>>>> Note Andrei I didn't see you react on my 2/3 threads about releasing :) > >>>>> , > >>>>> there is a last one open > >>>>> > >>>>>> Andrey Pokhilko > >>>>>> > >>>>>> On 04/04/2016 02:50 PM, Philippe Mouawad wrote: > >>>>>>> Yes it was a typo. > >>>>>>> This needs checking particularly for plugins that dynamically search > >>>>>>> for > >>>>>> a > >>>>>>> class implementing an interface. > >>>>>>> I don't have access to my computer but it's for example the > >>>>>>> class/method > >>>>>>> that is used in ViewResultsTree to search for renderers. There are > >>>>>>> other > >>>>>>> place where such mechanism is used. > >>>>>>> We need to be sure that placing plugin and dependencies in the same > >>>>>> folder > >>>>>>> will not break this part. > >>>>>>> > >>>>>>> Regards > >>>>>>> Philippe > >>>>>>> > >>>>>>> On Monday, April 4, 2016, Andrey Pokhilko <a...@ya.ru> wrote: > >>>>>>> > >>>>>>>> I assume "we do plugin dependencies go" is misprint for "where". > >>>>>>>> > >>>>>>>> The idea is to make plugins dirs self-sufficient and, most important, > >>>>>>>> don't touch jmeter's core "lib" and "lib/ext" dirs with plugins. > >>>>>>>> > >>>>>>>> No recursive search implied, just flat list of jars in directory > >>>>>> expected. > >>>>>>>> For example, both file of ssh-sampler plugin would be in its dir: > >>>>>>>> > >>>>>>>> jmeter > >>>>>>>> \ lib > >>>>>>>> \ 3rdparty > >>>>>>>> \ ssh-sampler > >>>>>>>> \ ssh-sampler-1.0.jar > >>>>>>>> | jsh-1.2.3.jar > >>>>>>>> > >>>>>>>> > >>>>>>>> Andrey Pokhilko > >>>>>>>> > >>>>>>>> On 04/04/2016 02:37 PM, Philippe Mouawad wrote: > >>>>>>>>> Hi Andrei, > >>>>>>>>> With this approach, we do plugin dependencies go ? > >>>>>>>>> > >>>>>>>>> Thanks > >>>>>>>>> > >>>>>>>>> On Monday, April 4, 2016, Andrey Pokhilko <a...@ya.ru > >>>>>>>>> <javascript:;>> > >>>>>>>> wrote: > >>>>>>>>>> I'm fine with not putting this into 3.0, if it's important for you > >>>>>>>>>> to > >>>>>>>>>> release it ASAP and you see a risk with this addition. I myself > >>>>>>>>>> don't > >>>>>>>>>> see any risks as long as change is made and reviewed carefully. > >>>>>>>>>> > >>>>>>>>>> With "search_paths" property, the problem is that user has to > >>>>>>>>>> reconfigure it for every new plugin set he installs. So instead of > >>>>>>>>>> simplifying life for user we would complicate it. "search_paths" > >>>>>>>>>> property implies that there's single and predictable plugins set > >>>>>>>>>> for > >>>>>>>>>> installation. My idea is to have directory structure agreement that > >>>>>>>>>> allows any number of separate plugin sets from any vendors. > >>>>>>>>>> > >>>>>>>>>> Andrey Pokhilko > >>>>>>>>>> > >>>>>>>>>> On 04/04/2016 02:24 PM, Philippe Mouawad wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> 3.0 is very close to release, I suggest we freeze new dev now and > >>>>>>>> release > >>>>>>>>>>> it. > >>>>>>>>>>> I have been asked tens of time when it's out. > >>>>>>>>>>> This can be done in 3.1 > >>>>>>>>>>> > >>>>>>>>>>> For info, this can already be done currently with search_paths > >>>>>> property > >>>>>>>>>> and > >>>>>>>>>>> user.classpath one. > >>>>>>>>>>> > >>>>>>>>>>> Regards > >>>>>>>>>>> > >>>>>>>>>>> On Monday, April 4, 2016, Refael Botbol <ref...@blazemeter.com > >>>>>>>> <javascript:;> > >>>>>>>>>> <javascript:;>> wrote: > >>>>>>>>>>>> I'm using lots of 3rd party plugins with JMeter and to me it will > >>>>>> make > >>>>>>>>>> life > >>>>>>>>>>>> much easier because: > >>>>>>>>>>>> > >>>>>>>>>>>> 1. If i'm installing a new plugin which crashes - i can > >>>>>>>>>>>> uninstall > >>>>>>>> it > >>>>>>>>>>>> quickly. > >>>>>>>>>>>> 2. It will give a clear list of which plugins I'm currently > >>>>>>>>>>>> using > >>>>>>>>>> incase > >>>>>>>>>>>> I need to run my script on a different machine > >>>>>>>>>>>> 3. Upgrading JMeter to a newer version will be almost seamless > >>>>>>>> (just > >>>>>>>>>>>> updating the path to my 3rd party plugin..) that way I don't > >>>>>>>>>>>> need > >>>>>>>> to > >>>>>>>>>>>> duplicate every plugin across multiple JMeter versions I have > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Mon, Apr 4, 2016 at 1:47 PM Andrey Pokhilko <a...@ya.ru > >>>>>>>> <javascript:;> > >>>>>>>>>> <javascript:;> <javascript:;>> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> No, I don't mean OSGification. I mean just classpath building. > >>>>>>>>>>>>> > >>>>>>>>>>>>> In case of library clash the earlier entry in classpath will > >>>>>>>>>>>>> win. > >>>>>> At > >>>>>>>>>>>>> least, there will be easy way to understand which plugins set > >>>>>> brings > >>>>>>>>>>>>> which library and reveal the plugins conflicts. For now, all > >>>>>>>>>>>>> guavas > >>>>>>>> go > >>>>>>>>>>>>> into "lib" and you look at it with no idea "why did it happen > >>>>>>>>>>>>> and > >>>>>> how > >>>>>>>>>> to > >>>>>>>>>>>>> go out of it". > >>>>>>>>>>>>> > >>>>>>>>>>>>> Andrey Pokhilko > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 04/04/2016 01:34 PM, Vladimir Sitnikov wrote: > >>>>>>>>>>>>>> Do you mean some kind of OSGification? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> What if different 3rdparties try to include different versions > >>>>>>>>>>>>>> of, > >>>>>>>>>> say, > >>>>>>>>>>>>> guava? > >>>>>>>>>>>>>> Which version will ultimately be loaded in your suggested > >>>>>> approach? > >>>>>>>>>>>>>> Vladimir > >>>>>>>>>>>>> -- > >>>>>>>>>>>> Refael Botbol, BlazeMeter. > >>>>>>>>>>>> Director of Professional Services > >>>>>>>>>>>> >
