I would rather see this in 3.0 than 3.1. From the point of view of the jmeter-maven-plugin this is a major change because we need to change where we programatically put plugins as we build up a jmeter file structure on the disk. From my point of view I would rather a big chance like this came in with a major version revision.
> On 4 Apr 2016, at 12:43, Andrey Pokhilko <[email protected]> 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 <[email protected]> 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 <[email protected] >>> <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 <[email protected] >>> <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 >>>>> >>> >
