jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Pokhilko <a...@ya.ru>
Subject Re: Separate folder for 3rd-party plugins
Date Mon, 04 Apr 2016 11:43:45 GMT
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