From dev-return-6302-apmail-jmeter-dev-archive=jmeter.apache.org@jmeter.apache.org Wed Apr 6 19:13:51 2016 Return-Path: X-Original-To: apmail-jmeter-dev-archive@minotaur.apache.org Delivered-To: apmail-jmeter-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 37CC719624 for ; Wed, 6 Apr 2016 19:13:51 +0000 (UTC) Received: (qmail 157 invoked by uid 500); 6 Apr 2016 19:13:51 -0000 Delivered-To: apmail-jmeter-dev-archive@jmeter.apache.org Received: (qmail 127 invoked by uid 500); 6 Apr 2016 19:13:51 -0000 Mailing-List: contact dev-help@jmeter.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jmeter.apache.org Delivered-To: mailing list dev@jmeter.apache.org Received: (qmail 116 invoked by uid 99); 6 Apr 2016 19:13:50 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Apr 2016 19:13:50 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 784631A001A for ; Wed, 6 Apr 2016 19:13:50 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.999 X-Spam-Level: X-Spam-Status: No, score=0.999 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, RP_MATCHES_RCVD=-0.001] autolearn=disabled Received: from mx2-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id y207qkxlIIu8 for ; Wed, 6 Apr 2016 19:13:48 +0000 (UTC) Received: from internetallee.de (internetallee.de [81.169.162.220]) by mx2-lw-eu.apache.org (ASF Mail Server at mx2-lw-eu.apache.org) with ESMTPS id B77275F3F4 for ; Wed, 6 Apr 2016 19:13:47 +0000 (UTC) Received: by internetallee.de (Postfix, from userid 5001) id A30364948899; Wed, 6 Apr 2016 21:13:41 +0200 (CEST) Received: from [192.168.178.24] (dslb-088-077-148-185.088.077.pools.vodafone-ip.de [88.77.148.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by internetallee.de (Postfix) with ESMTPSA id CE04C4948898 for ; Wed, 6 Apr 2016 21:13:36 +0200 (CEST) Message-ID: <1459970015.14347.2.camel@cat> Subject: Re: Separate folder for 3rd-party plugins From: Felix Schumacher To: dev@jmeter.apache.org Date: Wed, 06 Apr 2016 21:13:35 +0200 In-Reply-To: <570259CF.5080008@ya.ru> References: <57024024.6070802@ya.ru> <57024622.40402@ya.ru> <570250EE.2@ya.ru> <57025371.7040305@ya.ru> <570259CF.5080008@ya.ru> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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 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 > > >> 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 >> > >>>> > 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 >> > >>>> > > >>>>>> 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 > >>>>>> > >> >