Mailing-List: contact dev-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jmeter.apache.org
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Separate folder for 3rd-party plugins
From: Mark Collin <mark.collin@lazeryattack.com>
In-Reply-To: 
 <CAOGo0VYimYMfovQYNOry1AnFLdW_Tz12q+LeHdBOOPr3Xb3jrA@mail.gmail.com>
Date: Thu, 7 Apr 2016 12:08:57 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C3DA7447-6C22-4DD2-B207-D3FEE331E43C@lazeryattack.com>
References: <57024024.6070802@ya.ru>
 <CAB=Je-FMc-i6xE-7NuS3ASUZLFXB+1dDzggLEpdAnC+2jUAEfQ@mail.gmail.com>
 <57024622.40402@ya.ru>
 <CAPJQzCax5KxmocQfi6qhQe9F_AzoXpb-ObMiWkZSbw50JibkOA@mail.gmail.com>
 <CAH9fUpZR6Ragpm2sEKi08+UTJd9w+73=owZOPa7OnYFNB0XXXw@mail.gmail.com>
 <570250EE.2@ya.ru>
 <CAH9fUpaKLuZzPQvH21J961LwdydKZ_s+L9cgzMpPY05S2kw_Xw@mail.gmail.com>
 <57025371.7040305@ya.ru>
 <9DB3E086-DF35-4B03-8F62-436B31D44339@lazeryattack.com>
 <CAOGo0VYimYMfovQYNOry1AnFLdW_Tz12q+LeHdBOOPr3Xb3jrA@mail.gmail.com>
To: dev@jmeter.apache.org

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:
>=20
> 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.  =46rom 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.  =46rom my point of view I would rather a big =
chance like this came in with a major version revision.
>=20
> Huh?
>=20
> AIUI this would be in *addition* to the current methods of
> establishing the classpath.
>=20
> So it's extremely unlikely to affect your project.
>=20
> 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).
>=20
>>> On 4 Apr 2016, at 12:43, Andrey Pokhilko <apc4@ya.ru> wrote:
>>>=20
>>> I assume "we do plugin dependencies go" is misprint for "where".
>>>=20
>>> 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.
>>>=20
>>> No recursive search implied, just flat list of jars in directory =
expected.
>>>=20
>>> For example, both file of ssh-sampler plugin would be in its dir:
>>>=20
>>> jmeter
>>> \ lib
>>>  \ 3rdparty
>>>   \ ssh-sampler
>>>    \ ssh-sampler-1.0.jar
>>>    | jsh-1.2.3.jar
>>>=20
>>>=20
>>> Andrey Pokhilko
>>>=20
>>> On 04/04/2016 02:37 PM, Philippe Mouawad wrote:
>>>> Hi Andrei,
>>>> With this approach, we do plugin dependencies go ?
>>>>=20
>>>> Thanks
>>>>=20
>>>> On Monday, April 4, 2016, Andrey Pokhilko <apc4@ya.ru> wrote:
>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Andrey Pokhilko
>>>>>=20
>>>>> 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
>>>>>>=20
>>>>>> For info, this can already be done currently with search_paths =
property
>>>>> and
>>>>>> user.classpath one.
>>>>>>=20
>>>>>> Regards
>>>>>>=20
>>>>>> 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:
>>>>>>>=20
>>>>>>>  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
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Mon, Apr 4, 2016 at 1:47 PM Andrey Pokhilko <apc4@ya.ru
>>>>> <javascript:;> <javascript:;>>
>>>>>>> wrote:
>>>>>>>=20
>>>>>>>> No, I don't mean OSGification. I mean just classpath building.
>>>>>>>>=20
>>>>>>>> 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".
>>>>>>>>=20
>>>>>>>> Andrey Pokhilko
>>>>>>>>=20
>>>>>>>> On 04/04/2016 01:34 PM, Vladimir Sitnikov wrote:
>>>>>>>>> Do you mean some kind of OSGification?
>>>>>>>>>=20
>>>>>>>>> What if different 3rdparties try to include different versions =
of,
>>>>> say,
>>>>>>>> guava?
>>>>>>>>> Which version will ultimately be loaded in your suggested =
approach?
>>>>>>>>>=20
>>>>>>>>> Vladimir
>>>>>>>> --
>>>>>>> Refael Botbol, BlazeMeter.
>>>>>>> Director of Professional Services
>>>>>>>=20
>>>>>=20
>>>=20
>>=20