On 4 April 2016 at 14:34, Andrey Pokhilko <a...@ya.ru> wrote: > 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?
Yes, I object. Unless I am misunderstanding something there is *already* a mechanism for handling external jars and classes which is much more flexible. That is, the user.classpath property and the plugin_dependency_paths property. > 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 >>>>>>>>> >>> >
