buildbot failure in on jmeter-nightly

[buildbot]

The Buildbot has detected a new failure on builder jmeter-nightly while 
building . Full details are available at:
https://ci.apache.org/builders/jmeter-nightly/builds/280

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: hemera_ubuntu

Build Reason: The Nightly scheduler named 'jmeterNightly' triggered this build
Build Source Stamp: [branch jmeter/trunk] HEAD
Blamelist: 

BUILD FAILED: failed shell_5

Sincerely,
 -The Buildbot

Re: Display issue with the new JMeter logo in SVG format on docs pages

[Felix Schumacher]

Am 6. April 2016 21:44:19 MESZ, schrieb Milamber :
>Hello,
>
>Yes that works fine if you check the docs files directly from your file
>
>system (file://docs/etc..) but not with http:// (probably because 
>the mime type is detect by the browser, not send by the web server)
>
>Ok I found the real issue, it's was the Content-type from my Apache
>HTTP 
>server (version 2.2 from CentOS 5.11).
>
>The svg files are return with text/xml content type.
>
>I add this line in the configuration of httpd:
>
>|AddType image/svg+xml svg svgz AddEncoding gzip svgz And now that
>works, 
>with Firefox and IE 11 on Windows 10 (but not on Edge...) |
>
>Reference: https://davidwalsh.name/serve-svg-image
>
>The good news is that the HTTP server for JMeter.apache.org is Apache 
>2.4.7, I tests with a 2.4, and that works fine with all browsers 
>(include Edge) on my laptop, win10 and mobile phone without the
>addition 
>of AddType image/svg+xml
>
>So the svg image are very good to see with HiDPI, so I will change the 
>ASF logo with the SVG version on the JMeter docs

Good to hear. 

Felix

>
>Thanks for your tests.
>
>Milamber
>
>On 06/04/2016 16:23, Antonio Gomes Rodrigues wrote:
>> Hi
>>
>> No problem in my windows 10 + Edge or Windows 10 + Firefox or Windows
>10 +
>> Chrome
>>
>> Doc in jmeter\docs & jmeter\printable_docs
>>
>> Antonio
>>
>>
>>
>>
>
>> Garanti
>> sans virus. www.avast.com
>>
>
>> <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> 2016-04-05 21:18 GMT+02:00 Felix Schumacher <
>> felix.schumac...@internetallee.de>:
>>
>>>
>>> Am 4. April 2016 23:22:39 MESZ, schrieb Milamber
>:

 On 04/04/2016 18:02, Felix Schumacher wrote:
> Am 3. April 2016 21:40:12 MESZ, schrieb Milamber
 :
>> Hello,
>>
>> The new JMeter logo on the docs pages (site and printable) use
>the
 SVG
>> format. That is great for a better display on HiDPI screen.
>>
>> But I just saw that the SVG JMeter logo don't display on Edge
 browser
>> (windows 10) or Firefox (W10 too), on my firefox app in my
>phone...
> Can you try if it helps to add a height tag to the svg images?

 No, I try this without success.

 Perhaps, some ways to fix this with the svg fallback with png
 mechanism?

>https://www.google.com/search?q=svg+fallback+with+png=utf-8=utf-8
>>> I have tried with windows 10 and edge and the logo was clearly
>visible.
>>> Strange. Do you see the stars from the badges? Those are svg, too.
>>>
>>> Felix
>>>
 Milamber



>> Works fine on Firefox and Chrome on my Linux machine...
>>
>> Have you the same issue? We need to back to PNG format?
> I have no windows, so I can't reproduce the problem.
>
> Regards,
> Felix
>
>> Milamber
>>>

Re: Separate folder for 3rd-party plugins

[Felix Schumacher]

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 

Re: Separate folder for 3rd-party plugins

[Felix Schumacher]

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 

Re: Display issue with the new JMeter logo in SVG format on docs pages

[Antonio Gomes Rodrigues]

Hi

No problem in my windows 10 + Edge or Windows 10 + Firefox or Windows 10 +
Chrome

Doc in jmeter\docs & jmeter\printable_docs

Antonio




Garanti
sans virus. www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2016-04-05 21:18 GMT+02:00 Felix Schumacher <
felix.schumac...@internetallee.de>:

>
>
> Am 4. April 2016 23:22:39 MESZ, schrieb Milamber :
> >
> >
> >On 04/04/2016 18:02, Felix Schumacher wrote:
> >>
> >> Am 3. April 2016 21:40:12 MESZ, schrieb Milamber
> >:
> >>> Hello,
> >>>
> >>> The new JMeter logo on the docs pages (site and printable) use the
> >SVG
> >>> format. That is great for a better display on HiDPI screen.
> >>>
> >>> But I just saw that the SVG JMeter logo don't display on Edge
> >browser
> >>> (windows 10) or Firefox (W10 too), on my firefox app in my phone...
> >> Can you try if it helps to add a height tag to the svg images?
> >
> >
> >No, I try this without success.
> >
> >Perhaps, some ways to fix this with the svg fallback with png
> >mechanism?
> >https://www.google.com/search?q=svg+fallback+with+png=utf-8=utf-8
>
> I have tried with windows 10 and edge and the logo was clearly visible.
> Strange. Do you see the stars from the badges? Those are svg, too.
>
> Felix
>
> >
> >Milamber
> >
> >
> >
> >>
> >>> Works fine on Firefox and Chrome on my Linux machine...
> >>>
> >>> Have you the same issue? We need to back to PNG format?
> >> I have no windows, so I can't reproduce the problem.
> >>
> >> Regards,
> >> Felix
> >>
> >>> Milamber
> >>
>
>

Re: Separate folder for 3rd-party plugins

[sebb]

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

[Mark Collin]

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