jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Collin <mark.col...@lazeryattack.com>
Subject Re: Separate folder for 3rd-party plugins
Date Thu, 07 Apr 2016 11:08:57 GMT
If plugins placed in the 3rd party plugins folder are added to the class path in a different
order to the way they are added to the class path if we just dump them in the lib/ext folder
it will have an effect.

By putting things in the wrong folder we may be changing the order they are loaded in which
means that you will see different errors if you run through the plugin, or by physically putting
things in the correct folder.

> On 6 Apr 2016, at 11:38, sebb <sebbaz@gmail.com> wrote:
> 
> On 6 April 2016 at 11:00, Mark Collin <mark.collin@lazeryattack.com> wrote:
>> 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.
> 
> Huh?
> 
> AIUI this would be in *addition* to the current methods of
> establishing the classpath.
> 
> So it's extremely unlikely to affect your project.
> 
> If you think it will affect you, please say how, because it may affect
> others as well, and may affect the way it is implemented (assuming it
> is).
> 
>>> On 4 Apr 2016, at 12:43, Andrey Pokhilko <apc4@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 <apc4@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 <refael@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 <apc4@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
>>>>>>> 
>>>>> 
>>> 
>> 


Mime
View raw message