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 > >> > > > > -- Cordialement. Philippe Mouawad.
