Due to non-intrusive nature of the change, may I commit the change to become part of 3.0 before we got first RC?
Any objections? Andrey Pokhilko On 04/04/2016 03:36 PM, Philippe Mouawad wrote: > On Monday, April 4, 2016, Andrey Pokhilko <a...@ya.ru > <javascript:_e(%7B%7D,'cvml','a...@ya.ru');>> wrote: > >> 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 :) > > It is a 3.0 so it took a bit more time. > I think in future we should release more often (2/3 times a year unless > there's no need). > > Note Andrei I didn't see you react on my 2/3 threads about releasing :) , > there is a last one open > >> 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 >>>>>>>> >>
