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