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> 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:;>> 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:;>> >>>> 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 >>>> >>