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 12:56:55 GMT
Why don't you just start a vote on releasing? I think most mates have
nothing to say except vote +1 for releasing it. Otherwise they would say
it in reply to your requests.

Andrey Pokhilko

On 04/04/2016 03:36 PM, Philippe Mouawad wrote:
> On Monday, April 4, 2016, Andrey Pokhilko <apc4@ya.ru
> <javascript:_e(%7B%7D,'cvml','apc4@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 <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 <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 <refael@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 <apc4@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
>>>>>>>>
>>


Mime
View raw message