jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <felix.schumac...@internetallee.de>
Subject Re: Separate folder for 3rd-party plugins
Date Wed, 06 Apr 2016 19:13:35 GMT
Am Montag, den 04.04.2016, 15:10 +0300 schrieb Andrey Pokhilko:
> 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 :)

I don't want to wait another year for the next release neither. That is
independent of whether we include this feature, or not.

Felix

> 
> 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