Re: Separate folder for 3rd-party plugins
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
Re: Separate folder for 3rd-party plugins
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
Re: Separate folder for 3rd-party plugins
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
Re: Separate folder for 3rd-party plugins
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 > -- Cordialement. Philippe Mouawad.
Re: Separate folder for 3rd-party plugins
Code change would be approximately like this: https://github.com/Blazemeter/jmeter/commit/997c129a7579e015030f939c7f274b45d2805916 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
Re: Separate folder for 3rd-party plugins
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 >> >
Re: Separate folder for 3rd-party plugins
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 > >> > > > > -- Cordialement. Philippe Mouawad.
Re: Separate folder for 3rd-party plugins
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 >>
Re: Separate folder for 3rd-party plugins
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 > > >> > > -- Cordialement. Philippe Mouawad.
Re: Separate folder for 3rd-party plugins
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 :) 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 >> >>
Re: Separate folder for 3rd-party plugins
Andrey, 3rdparty/ssh-sampler misses "namespace" part. Does it make sense to use 3rdparty/yciabaud/jmeter-ssh-sampler kind of convention? If "3rdparty" folder is ever used, it should be present in out-of-the-box installation (e.g. with readme.txt inside) Vladimir
Re: Separate folder for 3rd-party plugins
I don't think that adding one more level of folder hierarchy is convenient. Directory name prefixes would perfectly solve that purpose for vendors with many plugins, keeping it simple for vendors with single plugin sets (the majority btw). I've already added the dir with readme as part of pull request. Andrey Pokhilko On 04/04/2016 03:15 PM, Vladimir Sitnikov wrote: > Andrey, > 3rdparty/ssh-sampler misses "namespace" part. > > Does it make sense to use 3rdparty/yciabaud/jmeter-ssh-sampler kind of > convention? > > If "3rdparty" folder is ever used, it should be present in > out-of-the-box installation (e.g. with readme.txt inside) > > Vladimir
Re: Separate folder for 3rd-party plugins
Andrey> I've already added the dir with readme as part of pull request. Technically speaking, PR 181 updates just src/core/org/apache/jmeter/NewDriver.java and src/core/org/apache/jmeter/util/JMeterUtils.java. I guess you missed to "git add" readme.txt. Vladimir
Re: Separate folder for 3rd-party plugins
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 > 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 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 m
Re: Separate folder for 3rd-party plugins
Due to non-intrusive nature of the change, may I commit the change to become part of 3.0 before we got first RC? Any objections? Andrey Pokhilko On 04/04/2016 03:36 PM, Philippe Mouawad wrote: > On Monday, April 4, 2016, Andrey Pokhilko > 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 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? >> >
Re: Separate folder for 3rd-party plugins
Flexibility is not always desirable. Andrey's idea enables easy deinstallation of plugins. To install a plugin, you unzip it to 3rdparty folder, to uninstall it you just drop the relevant folder. >From my point of view, "just unzip" kind of installation rocks if compared with "create new folder, unzip, modify properties, remember to keep those in sync when upgrading, etc, etc" Of course, you can mention each new plugin in the specified properties, however that does not scale well, taking into account that major number of users have absolutely no idea what the classpath is and how user.classpath is different from plugin_dependency_paths. Seriously. Am I missing something? Vladimir
Re: Separate folder for 3rd-party plugins
On 4 April 2016 at 14:34, Andrey Pokhilko wrote: > Due to non-intrusive nature of the change, may I commit the change to > become part of 3.0 before we got first RC? > > Any objections? Yes, I object. Unless I am misunderstanding something there is *already* a mechanism for handling external jars and classes which is much more flexible. That is, the user.classpath property and the plugin_dependency_paths property. > Andrey Pokhilko > > On 04/04/2016 03:36 PM, Philippe Mouawad wrote: >> On Monday, April 4, 2016, Andrey Pokhilko > > 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 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
Re: Separate folder for 3rd-party plugins
How does it help to remove complexity from user? Is there a way to seamlessly put bunch of files taken from plugin vendor and get them loaded by JMeter? It's not convenient way to require users to edit properties files every time they install plugins. Until now there was kinda "seamless" way of dropping JAR files into "lib" and "lib/ext", but it mixes core JARs with third-party JARs, making it difficult to solve possible conflicts. Why you object against some "new" mechanism in JMeter? Does it do any harm? Andrey Pokhilko On 04/04/2016 07:10 PM, sebb wrote: > On 4 April 2016 at 14:34, Andrey Pokhilko wrote: >> Due to non-intrusive nature of the change, may I commit the change to >> become part of 3.0 before we got first RC? >> >> Any objections? > Yes, I object. > > Unless I am misunderstanding something there is *already* a mechanism > for handling external jars and classes which is much more flexible. > > That is, the user.classpath property and the plugin_dependency_paths property. > >> Andrey Pokhilko >> >> On 04/04/2016 03:36 PM, Philippe Mouawad wrote: >>> On Monday, April 4, 2016, Andrey Pokhilko >> > 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 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 o
Re: Separate folder for 3rd-party plugins
I am -1 for adding this in 3.0 I don't think there's enough time to consider whether it truly is non-intrusive or even whether it is the best solution. It took quite a while to sort out JMeter class paths to ensure that classes are only loaded when necessary. The more jars there are in core JMeter, the more this becomes important to minimise memory consumption. It may turn out to be OK, but this is not something that can be added at the last minute. On 4 April 2016 at 17:19, Andrey Pokhilko wrote: > How does it help to remove complexity from user? Is there a way to > seamlessly put bunch of files taken from plugin vendor and get them > loaded by JMeter? It's not convenient way to require users to edit > properties files every time they install plugins. > > Until now there was kinda "seamless" way of dropping JAR files into > "lib" and "lib/ext", but it mixes core JARs with third-party JARs, > making it difficult to solve possible conflicts. > > Why you object against some "new" mechanism in JMeter? Does it do any harm? > > Andrey Pokhilko > > On 04/04/2016 07:10 PM, sebb wrote: >> On 4 April 2016 at 14:34, Andrey Pokhilko wrote: >>> Due to non-intrusive nature of the change, may I commit the change to >>> become part of 3.0 before we got first RC? >>> >>> Any objections? >> Yes, I object. >> >> Unless I am misunderstanding something there is *already* a mechanism >> for handling external jars and classes which is much more flexible. >> >> That is, the user.classpath property and the plugin_dependency_paths >> property. >> >>> Andrey Pokhilko >>> >>> On 04/04/2016 03:36 PM, Philippe Mouawad wrote: On Monday, April 4, 2016, Andrey Pokhilko >>> > 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 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. >>>
Re: Separate folder for 3rd-party plugins
That makes sense. The question of "when add it" is separate from "if add it". If your objection is only for "when" then we have a time to discuss the idea. Actually, I see an opportunity for this mechanism to actually slurp in some of JMeter core plugin sets, like "mongodb", "mail" or "ftp" or others. The way of "put JMeter functionality into same bucket with its dependencies" might allow to isolate JARs that are rarely used and allow to not load them in certain cases. This would crystallize core libraries from functionality libraries, opening door to manage it. I understand that JMeter's core is "time-proven", but time changes and world evolves around us. At the time the core loading pieces were created, there were not as many plugins and vendors. And now there are tens of them. Makes sense to evolve the tool to reflect new realities. sebb, can you review the code and say your opinion if it is truly non-intrusive? Others, can you express your opinion on this feature/idea? Milamber, Felix? Andrey Pokhilko On 04/04/2016 07:30 PM, sebb wrote: > I am -1 for adding this in 3.0 > > I don't think there's enough time to consider whether it truly is > non-intrusive or even whether it is the best solution. > > It took quite a while to sort out JMeter class paths to ensure that > classes are only loaded when necessary. > The more jars there are in core JMeter, the more this becomes > important to minimise memory consumption. > > It may turn out to be OK, but this is not something that can be added > at the last minute. > > > On 4 April 2016 at 17:19, Andrey Pokhilko wrote: >> How does it help to remove complexity from user? Is there a way to >> seamlessly put bunch of files taken from plugin vendor and get them >> loaded by JMeter? It's not convenient way to require users to edit >> properties files every time they install plugins. >> >> Until now there was kinda "seamless" way of dropping JAR files into >> "lib" and "lib/ext", but it mixes core JARs with third-party JARs, >> making it difficult to solve possible conflicts. >> >> Why you object against some "new" mechanism in JMeter? Does it do any harm? >> >> Andrey Pokhilko >> >> On 04/04/2016 07:10 PM, sebb wrote: >>> On 4 April 2016 at 14:34, Andrey Pokhilko wrote: Due to non-intrusive nature of the change, may I commit the change to become part of 3.0 before we got first RC? Any objections? >>> Yes, I object. >>> >>> Unless I am misunderstanding something there is *already* a mechanism >>> for handling external jars and classes which is much more flexible. >>> >>> That is, the user.classpath property and the plugin_dependency_paths >>> property. >>> Andrey Pokhilko On 04/04/2016 03:36 PM, Philippe Mouawad wrote: > On Monday, April 4, 2016, Andrey Pokhilko > 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 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 Andre
Re: Separate folder for 3rd-party plugins
+1 for inclusion if it does delay again 3.0 It does not seem to be a big deal and it makes things easier for users, so ok for me On Monday, April 4, 2016, Andrey Pokhilko wrote: > That makes sense. > > The question of "when add it" is separate from "if add it". If your > objection is only for "when" then we have a time to discuss the idea. > > Actually, I see an opportunity for this mechanism to actually slurp in > some of JMeter core plugin sets, like "mongodb", "mail" or "ftp" or > others. The way of "put JMeter functionality into same bucket with its > dependencies" might allow to isolate JARs that are rarely used and allow > to not load them in certain cases. This would crystallize core libraries > from functionality libraries, opening door to manage it. > > I understand that JMeter's core is "time-proven", but time changes and > world evolves around us. At the time the core loading pieces were > created, there were not as many plugins and vendors. And now there are > tens of them. Makes sense to evolve the tool to reflect new realities. > > sebb, can you review the code and say your opinion if it is truly > non-intrusive? > > Others, can you express your opinion on this feature/idea? Milamber, Felix? > > Andrey Pokhilko > > On 04/04/2016 07:30 PM, sebb wrote: > > I am -1 for adding this in 3.0 > > > > I don't think there's enough time to consider whether it truly is > > non-intrusive or even whether it is the best solution. > > > > It took quite a while to sort out JMeter class paths to ensure that > > classes are only loaded when necessary. > > The more jars there are in core JMeter, the more this becomes > > important to minimise memory consumption. > > > > It may turn out to be OK, but this is not something that can be added > > at the last minute. > > > > > > On 4 April 2016 at 17:19, Andrey Pokhilko > > wrote: > >> How does it help to remove complexity from user? Is there a way to > >> seamlessly put bunch of files taken from plugin vendor and get them > >> loaded by JMeter? It's not convenient way to require users to edit > >> properties files every time they install plugins. > >> > >> Until now there was kinda "seamless" way of dropping JAR files into > >> "lib" and "lib/ext", but it mixes core JARs with third-party JARs, > >> making it difficult to solve possible conflicts. > >> > >> Why you object against some "new" mechanism in JMeter? Does it do any > harm? > >> > >> Andrey Pokhilko > >> > >> On 04/04/2016 07:10 PM, sebb wrote: > >>> On 4 April 2016 at 14:34, Andrey Pokhilko > > wrote: > Due to non-intrusive nature of the change, may I commit the change to > become part of 3.0 before we got first RC? > > Any objections? > >>> Yes, I object. > >>> > >>> Unless I am misunderstanding something there is *already* a mechanism > >>> for handling external jars and classes which is much more flexible. > >>> > >>> That is, the user.classpath property and the plugin_dependency_paths > property. > >>> > Andrey Pokhilko > > On 04/04/2016 03:36 PM, Philippe Mouawad wrote: > > On Monday, April 4, 2016, Andrey Pokhilko > > ');>> 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 > 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 to
Re: Separate folder for 3rd-party plugins
I like the idea of having "per-directory" plugins. It could probably evolve to "start JMeter without plugins" or "enable-disable plugin from a menu". What makes me a bit sad, PR 181 does not provide tests (it does not test that new folder works as expected). I have no strong opinion regarding inclusion of the feature to 3.0 vs 3.1 . I have no idea how much resources it takes to release JMeter. If possible, it could make sense to release more often, so we do not have to vote on "delay current release vs move a feature to the next one". The feature looks not that intrusive (provided it is tested), and it looks to be of a great use, so +0...+1 for inclusion the feature into 3.0. Vladimir
Re: Separate folder for 3rd-party plugins
I would rather see this in 3.0 than 3.1. From 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. From my point of view I would rather a big chance like this came in with a major version revision. > On 4 Apr 2016, at 12:43, 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 > >>> >
Re: Separate folder for 3rd-party plugins
On 6 April 2016 at 11:00, Mark Collin wrote: > I would rather see this in 3.0 than 3.1. From 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. From my point of view I would rather a big chance like this came in > with a major version revision. Huh? AIUI this would be in *addition* to the current methods of establishing the classpath. So it's extremely unlikely to affect your project. 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). >> On 4 Apr 2016, at 12:43, 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 >> >> >
Re: Separate folder for 3rd-party plugins
Am Montag, den 04.04.2016, 13:24 +0200 schrieb Philippe Mouawad: > 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. ./bin/jmeter -Jsearch_paths="$(find lib/plugins/ -maxdepth 1 -mindepth 1 -type d | paste -s -d ';')" :) Felix > > 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 > > > >
Re: Separate folder for 3rd-party plugins
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 > >> > >> >
Re: Separate folder for 3rd-party plugins
Am Montag, den 04.04.2016, 19:44 +0300 schrieb Andrey Pokhilko: > That makes sense. > > The question of "when add it" is separate from "if add it". If your > objection is only for "when" then we have a time to discuss the idea. > > Actually, I see an opportunity for this mechanism to actually slurp in > some of JMeter core plugin sets, like "mongodb", "mail" or "ftp" or > others. The way of "put JMeter functionality into same bucket with its > dependencies" might allow to isolate JARs that are rarely used and allow > to not load them in certain cases. This would crystallize core libraries > from functionality libraries, opening door to manage it. > > I understand that JMeter's core is "time-proven", but time changes and > world evolves around us. At the time the core loading pieces were > created, there were not as many plugins and vendors. And now there are > tens of them. Makes sense to evolve the tool to reflect new realities. > > sebb, can you review the code and say your opinion if it is truly > non-intrusive? > > Others, can you express your opinion on this feature/idea? Milamber, Felix? I don't want to include it in 3.0, but I think a standard way to include thirdparty libraries apart from editing jmeter.properties is a nice feature to have. Felix > > Andrey Pokhilko > > On 04/04/2016 07:30 PM, sebb wrote: > > I am -1 for adding this in 3.0 > > > > I don't think there's enough time to consider whether it truly is > > non-intrusive or even whether it is the best solution. > > > > It took quite a while to sort out JMeter class paths to ensure that > > classes are only loaded when necessary. > > The more jars there are in core JMeter, the more this becomes > > important to minimise memory consumption. > > > > It may turn out to be OK, but this is not something that can be added > > at the last minute. > > > > > > On 4 April 2016 at 17:19, Andrey Pokhilko wrote: > >> How does it help to remove complexity from user? Is there a way to > >> seamlessly put bunch of files taken from plugin vendor and get them > >> loaded by JMeter? It's not convenient way to require users to edit > >> properties files every time they install plugins. > >> > >> Until now there was kinda "seamless" way of dropping JAR files into > >> "lib" and "lib/ext", but it mixes core JARs with third-party JARs, > >> making it difficult to solve possible conflicts. > >> > >> Why you object against some "new" mechanism in JMeter? Does it do any harm? > >> > >> Andrey Pokhilko > >> > >> On 04/04/2016 07:10 PM, sebb wrote: > >>> On 4 April 2016 at 14:34, Andrey Pokhilko wrote: > Due to non-intrusive nature of the change, may I commit the change to > become part of 3.0 before we got first RC? > > Any objections? > >>> Yes, I object. > >>> > >>> Unless I am misunderstanding something there is *already* a mechanism > >>> for handling external jars and classes which is much more flexible. > >>> > >>> That is, the user.classpath property and the plugin_dependency_paths > >>> property. > >>> > Andrey Pokhilko > > On 04/04/2016 03:36 PM, Philippe Mouawad wrote: > > On Monday, April 4, 2016, Andrey Pokhilko > > 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 wrote: > >>> > I assume "we do plugin dependencies go" is misprint for "where". > > The idea is to make
Re: Separate folder for 3rd-party plugins
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 wrote: > > On 6 April 2016 at 11:00, Mark Collin wrote: >> I would rather see this in 3.0 than 3.1. From 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. From my point of view I would rather a big chance like this came in >> with a major version revision. > > Huh? > > AIUI this would be in *addition* to the current methods of > establishing the classpath. > > So it's extremely unlikely to affect your project. > > 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). > >>> On 4 Apr 2016, at 12:43, 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 >>> > >>> >>
Re: Separate folder for 3rd-party plugins
On 7 April 2016 at 12:08, Mark Collin wrote: > 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. JMeter does not guarantee any particular order of loading jars within the lib/ext folder; in particular the order may vary on different OSes. So if the ordering is important that is *already* a potential problem. However, the order in which jars are loaded makes a difference, it seems to me that this is a problem with the jars, not with JMeter. AFAIK there's no particular ordering guaranteed with other apps such as Tomcat. Or indeed Maven. The solution is to ensure that there is only ever a single instance of each class defined in any of the jars that are loaded. Otherwise there will be problems at some point. > 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 wrote: >> >> On 6 April 2016 at 11:00, Mark Collin wrote: >>> I would rather see this in 3.0 than 3.1. From 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. From my point of view I would rather a big chance like this came >>> in with a major version revision. >> >> Huh? >> >> AIUI this would be in *addition* to the current methods of >> establishing the classpath. >> >> So it's extremely unlikely to affect your project. >> >> 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). >> On 4 Apr 2016, at 12:43, 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
Re: Separate folder for 3rd-party plugins
sebb>The solution is to ensure that there is only ever a single instance of sebb>each class defined in any of the jars that are loaded. sebb>Otherwise there will be problems at some point. +1 Vladimir
Re: Separate folder for 3rd-party plugins
It doesn’t right now, but unless I’m reading the description of the PR wrong, it will once this 3rd party libs folder is added. That’s a pretty big change in my mind. > On 7 Apr 2016, at 16:25, sebb wrote: > > On 7 April 2016 at 12:08, Mark Collin wrote: >> 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. > > JMeter does not guarantee any particular order of loading jars within > the lib/ext folder; in particular the order may vary on different > OSes. > > So if the ordering is important that is *already* a potential problem. > > However, the order in which jars are loaded makes a difference, it > seems to me that this is a problem with the jars, not with JMeter. > > AFAIK there's no particular ordering guaranteed with other apps such as > Tomcat. > Or indeed Maven. > > The solution is to ensure that there is only ever a single instance of > each class defined in any of the jars that are loaded. > Otherwise there will be problems at some point. > >> 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 wrote: >>> >>> On 6 April 2016 at 11:00, Mark Collin wrote: I would rather see this in 3.0 than 3.1. From 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. From my point of view I would rather a big chance like this came in with a major version revision. >>> >>> Huh? >>> >>> AIUI this would be in *addition* to the current methods of >>> establishing the classpath. >>> >>> So it's extremely unlikely to affect your project. >>> >>> 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). >>> > On 4 Apr 2016, at 12:43, 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
Re: Separate folder for 3rd-party plugins
On 8 April 2016 at 15:02, Mark Collin wrote: > It doesn’t right now, but unless I’m reading the description of the PR wrong, > it will once this 3rd party libs folder is added. > > That’s a pretty big change in my mind. Sorry, I don't follow what you think has changed. >> On 7 Apr 2016, at 16:25, sebb wrote: >> >> On 7 April 2016 at 12:08, Mark Collin wrote: >>> 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. >> >> JMeter does not guarantee any particular order of loading jars within >> the lib/ext folder; in particular the order may vary on different >> OSes. >> >> So if the ordering is important that is *already* a potential problem. >> >> However, the order in which jars are loaded makes a difference, it >> seems to me that this is a problem with the jars, not with JMeter. >> >> AFAIK there's no particular ordering guaranteed with other apps such as >> Tomcat. >> Or indeed Maven. >> >> The solution is to ensure that there is only ever a single instance of >> each class defined in any of the jars that are loaded. >> Otherwise there will be problems at some point. >> >>> 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 wrote: On 6 April 2016 at 11:00, Mark Collin wrote: > I would rather see this in 3.0 than 3.1. From 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. From my point of view I would rather a big chance > like this came in with a major version revision. Huh? AIUI this would be in *addition* to the current methods of establishing the classpath. So it's extremely unlikely to affect your project. 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). >> On 4 Apr 2016, at 12:43, 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 >>>