Am Montag, den 04.04.2016, 15:10 +0300 schrieb Andrey Pokhilko: > 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 :)
I don't want to wait another year for the next release neither. That is independent of whether we include this feature, or not. Felix > > 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 > >>>>>> > >> >
