You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Philippe Mouawad <ph...@gmail.com> on 2016/03/02 23:06:07 UTC
Re: About including Groovy
Hello,
For information , we had a vote on our twitter account:
- https://twitter.com/apachejmeter/status/702590631571496961
Results are the following:
Participation : 100 Votes
- 9% NO
- 91% YES
This has no particular value except to give a kind of feeling about it.
>From this discussion it appears we have a move towards including it.
Unless there is a NOGO I will start bundling 2.4.6 groovy-all in jmeter
tomorrow evening.
Regards
Philippe
On Thu, Feb 25, 2016 at 3:53 AM, Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> TL;DR: +1 for bundling proper groovy.jar with JMeter.
>
> Alternative approach would be some kind of "online store to download
> JMeter plugins". I am not sure if that can be done in a reasonable
> time frame though.
>
> In my opinion, there are number of advantages for bundling Groovy:
> 1) I can easily get a "online groovy console", so I can easily check
> if -3.abs() returns 3 or -3. That is exactly JMeter users have to do.
> JMeter (as IDE) does not provide ability to execute small parts of
> code, thus users have to use their minds (or Google or whatever) to
> craft code that works. I claim using Groovy online console helps a
> lot. With BeanShell you never know if your code will work until you
> run it.
>
> groovyconsole.appspot.com just blows BeanShell out of the water.
>
> 2) "Groovy is in active development, thus everybody would have to
> constantly update groovy.jar anyway" is not justified.
> Even though there will be new groovy.jar releases, it is unlikely
> users will use cutting-edge features of Groovy language in JMeter
> scenarios.
>
> I think the main usage would be just regular boilerplate code, so
> non-experts would never be able to write Groovy code that requires the
> latest groovy.jar to execute.
>
> 3) Even though I prefer not to use Groovy, I see no better replacement
> for glue code in JMeter's samplers. In fact, it could even make sense
> to add a menu entry like "create groovy samlper". That way users could
> access it without secret knowledge of what JSR223 means.
>
> 4) Groovy's Java interop is much better designed from language point
> of view than the one of JavaScript. I mean it is just much easier to
> call java libraries since that was considered by Groovy language
> designers. This somewhat rules out JavaScript. BeanShell is too
> verbose and it does not seem to be the right tool as a glue language.
>
> As a Java programmer, I'm much more fluent in "Groovy+groovyconsole"
> than in "BeanShell+no_way_to_validate_snippet".
> I'm fluent in JavaScript, yet it does not help me to answer "how to
> read/write a file". Rhino/Nashorn have java interop, yet it is not in
> my active vocabulary, thus I would prefer groovy.
>
> 5) It is a bit hard to pick the proper groovy jar.
>
> 6) At the end of the day, "valid java code is valid Groovy code"
>
> 7) Having Groovy in JMeter would add nice "backward compatibility"
> feature. Suppose JMeter 3.0 includes Groovy. Then load scripts would
> work in exactly the same way for all the users of JMeter 3.0. If
> everybody downloads his/her own version of Groovy, that would easily
> result in "JMeter script broken for unknown reason" or even "wrong
> results due to newer/incompatible groovy.jar version".
>
>
> sebb> The only advantage I can see is that JMeter users don't have to
> sebb> download Groovy in order to use it.
>
> That is huge advantage.
> Current http://groovy-lang.org/download.html is not designed for
> downloading a single jar file.
> "apache-groovy-binary...zip" is 35MiB zip file with lots of jars
> inside. Technically speaking, 52 of them start with "groovy-"
> I do not want to learn/read which groovy jar I need. I just want to
> make JMeter work.
>
> Milamber>2/ Why Beanshell is including in JMeter and not Groovy?
>
> I think it might be a good time to deprecate BeanShell. Not in a sense
> "remove it in the subsequent release", but in order to clean up menus,
> etc, etc. One never has excessive screen space, so removing BeanShell
> menus seems wise from my point of view.
>
>
> sebb> This adds aboiut 5% to the total jar size.
>
> That is OK from my point of view.
>
> Current apache-jmeter-2.13.zip includes:
> 1) Lots of javadocs (docs/api). 46MiB when unzipped. That is more than
> 50% of the JMeter (82MiB is the net volume of unzipped JMeter 2.13).
> If removing docs/api, the zip file takes 5MiB less. I'm not sure
> javadocs need be the part of regular JMeter binary zip.
>
> 2) Current docs/images/screenshots takes 12MiB. It can likely be fit
> under 5MiB (~save 10MiB) if crunched through a png optimizer.
>
> Vladimir
>
--
Cordialement.
Philippe Mouawad.
Re: About including Groovy
Posted by Philippe Mouawad <ph...@gmail.com>.
Hi,
Groovy-all bundled within
https://bz.apache.org/bugzilla/show_bug.cgi?id=58715
Tests are welcome on nightly build
Regards
On Thursday, March 3, 2016, sebb <se...@gmail.com> wrote:
> On 3 March 2016 at 11:31, Philippe Mouawad <philippe.mouawad@gmail.com
> <javascript:;>> wrote:
> > On Thursday, March 3, 2016, sebb <sebbaz@gmail.com <javascript:;>>
> wrote:
> >
> >> On 3 March 2016 at 06:37, Philippe Mouawad <philippe.mouawad@gmail.com
> <javascript:;>
> >> <javascript:;>> wrote:
> >> > On Thursday, March 3, 2016, sebb <sebbaz@gmail.com <javascript:;>
> <javascript:;>>
> >> wrote:
> >> >
> >> >> On 2 March 2016 at 22:06, Philippe Mouawad <
> philippe.mouawad@gmail.com <javascript:;>
> >> <javascript:;>
> >> >> <javascript:;>> wrote:
> >> >> > Hello,
> >> >> > For information , we had a vote on our twitter account:
> >> >> > - https://twitter.com/apachejmeter/status/702590631571496961
> >> >> >
> >> >> > Results are the following:
> >> >> > Participation : 100 Votes
> >> >> > - 9% NO
> >> >>
> >> >> What reasons were given for saying no?
> >> >
> >> >
> >> > People don't give an explanation for their vote on twitter.
> >> > But you can read by clicking on the link above the replies to the
> voting
> >> > tweet to see 2 or 3 reasons for no and the same for yes.
> >>
> >> I only see 6 votes there; the proportions are 50-50.
> >> All the No votes are about keeping JMeter light-weight.
> >>
> >> There does not seem to be a way to see the other votes.
> >
> >
> > you're mixing votes and replies to tweets.
>
> I see.
>
> > Vote give 91%
> > Besides in this thread, majority of comments are for a bundling.
> >
> > But if you want we can start a technical vote on this although I think
> it's
> > a lot of energy spent.
>
> I was just curious if there was any other reason apart from added size.
>
> >>
> >> >>
> >> >> > - 91% YES
> >> >> >
> >> >> >
> >> >> > This has no particular value except to give a kind of feeling about
> >> it.
> >> >> >
> >> >> > From this discussion it appears we have a move towards including
> it.
> >> >> >
> >> >> > Unless there is a NOGO I will start bundling 2.4.6 groovy-all in
> >> jmeter
> >> >> > tomorrow evening.
> >> >> >
> >> >> > Regards
> >> >> > Philippe
> >> >> >
> >> >> > On Thu, Feb 25, 2016 at 3:53 AM, Vladimir Sitnikov <
> >> >> > sitnikov.vladimir@gmail.com <javascript:;> <javascript:;>
> <javascript:;>> wrote:
> >> >> >
> >> >> >> TL;DR: +1 for bundling proper groovy.jar with JMeter.
> >> >> >>
> >> >> >> Alternative approach would be some kind of "online store to
> download
> >> >> >> JMeter plugins". I am not sure if that can be done in a reasonable
> >> >> >> time frame though.
> >> >> >>
> >> >> >> In my opinion, there are number of advantages for bundling Groovy:
> >> >> >> 1) I can easily get a "online groovy console", so I can easily
> check
> >> >> >> if -3.abs() returns 3 or -3. That is exactly JMeter users have to
> do.
> >> >> >> JMeter (as IDE) does not provide ability to execute small parts of
> >> >> >> code, thus users have to use their minds (or Google or whatever)
> to
> >> >> >> craft code that works. I claim using Groovy online console helps a
> >> >> >> lot. With BeanShell you never know if your code will work until
> you
> >> >> >> run it.
> >> >> >>
> >> >> >> groovyconsole.appspot.com just blows BeanShell out of the water.
> >> >> >>
> >> >> >> 2) "Groovy is in active development, thus everybody would have to
> >> >> >> constantly update groovy.jar anyway" is not justified.
> >> >> >> Even though there will be new groovy.jar releases, it is unlikely
> >> >> >> users will use cutting-edge features of Groovy language in JMeter
> >> >> >> scenarios.
> >> >> >>
> >> >> >> I think the main usage would be just regular boilerplate code, so
> >> >> >> non-experts would never be able to write Groovy code that requires
> >> the
> >> >> >> latest groovy.jar to execute.
> >> >> >>
> >> >> >> 3) Even though I prefer not to use Groovy, I see no better
> >> replacement
> >> >> >> for glue code in JMeter's samplers. In fact, it could even make
> sense
> >> >> >> to add a menu entry like "create groovy samlper". That way users
> >> could
> >> >> >> access it without secret knowledge of what JSR223 means.
> >> >> >>
> >> >> >> 4) Groovy's Java interop is much better designed from language
> point
> >> >> >> of view than the one of JavaScript. I mean it is just much easier
> to
> >> >> >> call java libraries since that was considered by Groovy language
> >> >> >> designers. This somewhat rules out JavaScript. BeanShell is too
> >> >> >> verbose and it does not seem to be the right tool as a glue
> language.
> >> >> >>
> >> >> >> As a Java programmer, I'm much more fluent in
> "Groovy+groovyconsole"
> >> >> >> than in "BeanShell+no_way_to_validate_snippet".
> >> >> >> I'm fluent in JavaScript, yet it does not help me to answer "how
> to
> >> >> >> read/write a file". Rhino/Nashorn have java interop, yet it is
> not in
> >> >> >> my active vocabulary, thus I would prefer groovy.
> >> >> >>
> >> >> >> 5) It is a bit hard to pick the proper groovy jar.
> >> >> >>
> >> >> >> 6) At the end of the day, "valid java code is valid Groovy code"
> >> >> >>
> >> >> >> 7) Having Groovy in JMeter would add nice "backward compatibility"
> >> >> >> feature. Suppose JMeter 3.0 includes Groovy. Then load scripts
> would
> >> >> >> work in exactly the same way for all the users of JMeter 3.0. If
> >> >> >> everybody downloads his/her own version of Groovy, that would
> easily
> >> >> >> result in "JMeter script broken for unknown reason" or even "wrong
> >> >> >> results due to newer/incompatible groovy.jar version".
> >> >> >>
> >> >> >>
> >> >> >> sebb> The only advantage I can see is that JMeter users don't
> have to
> >> >> >> sebb> download Groovy in order to use it.
> >> >> >>
> >> >> >> That is huge advantage.
> >> >> >> Current http://groovy-lang.org/download.html is not designed for
> >> >> >> downloading a single jar file.
> >> >> >> "apache-groovy-binary...zip" is 35MiB zip file with lots of jars
> >> >> >> inside. Technically speaking, 52 of them start with "groovy-"
> >> >> >> I do not want to learn/read which groovy jar I need. I just want
> to
> >> >> >> make JMeter work.
> >> >> >>
> >> >> >> Milamber>2/ Why Beanshell is including in JMeter and not Groovy?
> >> >> >>
> >> >> >> I think it might be a good time to deprecate BeanShell. Not in a
> >> sense
> >> >> >> "remove it in the subsequent release", but in order to clean up
> >> menus,
> >> >> >> etc, etc. One never has excessive screen space, so removing
> BeanShell
> >> >> >> menus seems wise from my point of view.
> >> >> >>
> >> >> >>
> >> >> >> sebb> This adds aboiut 5% to the total jar size.
> >> >> >>
> >> >> >> That is OK from my point of view.
> >> >> >>
> >> >> >> Current apache-jmeter-2.13.zip includes:
> >> >> >> 1) Lots of javadocs (docs/api). 46MiB when unzipped. That is more
> >> than
> >> >> >> 50% of the JMeter (82MiB is the net volume of unzipped JMeter
> 2.13).
> >> >> >> If removing docs/api, the zip file takes 5MiB less. I'm not sure
> >> >> >> javadocs need be the part of regular JMeter binary zip.
> >> >> >>
> >> >> >> 2) Current docs/images/screenshots takes 12MiB. It can likely be
> fit
> >> >> >> under 5MiB (~save 10MiB) if crunched through a png optimizer.
> >> >> >>
> >> >> >> Vladimir
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Cordialement.
> >> >> > Philippe Mouawad.
> >> >>
> >> >
> >> >
> >> > --
> >> > Cordialement.
> >> > Philippe Mouawad.
> >>
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>
--
Cordialement.
Philippe Mouawad.
Re: About including Groovy
Posted by sebb <se...@gmail.com>.
On 3 March 2016 at 11:31, Philippe Mouawad <ph...@gmail.com> wrote:
> On Thursday, March 3, 2016, sebb <se...@gmail.com> wrote:
>
>> On 3 March 2016 at 06:37, Philippe Mouawad <philippe.mouawad@gmail.com
>> <javascript:;>> wrote:
>> > On Thursday, March 3, 2016, sebb <sebbaz@gmail.com <javascript:;>>
>> wrote:
>> >
>> >> On 2 March 2016 at 22:06, Philippe Mouawad <philippe.mouawad@gmail.com
>> <javascript:;>
>> >> <javascript:;>> wrote:
>> >> > Hello,
>> >> > For information , we had a vote on our twitter account:
>> >> > - https://twitter.com/apachejmeter/status/702590631571496961
>> >> >
>> >> > Results are the following:
>> >> > Participation : 100 Votes
>> >> > - 9% NO
>> >>
>> >> What reasons were given for saying no?
>> >
>> >
>> > People don't give an explanation for their vote on twitter.
>> > But you can read by clicking on the link above the replies to the voting
>> > tweet to see 2 or 3 reasons for no and the same for yes.
>>
>> I only see 6 votes there; the proportions are 50-50.
>> All the No votes are about keeping JMeter light-weight.
>>
>> There does not seem to be a way to see the other votes.
>
>
> you're mixing votes and replies to tweets.
I see.
> Vote give 91%
> Besides in this thread, majority of comments are for a bundling.
>
> But if you want we can start a technical vote on this although I think it's
> a lot of energy spent.
I was just curious if there was any other reason apart from added size.
>>
>> >>
>> >> > - 91% YES
>> >> >
>> >> >
>> >> > This has no particular value except to give a kind of feeling about
>> it.
>> >> >
>> >> > From this discussion it appears we have a move towards including it.
>> >> >
>> >> > Unless there is a NOGO I will start bundling 2.4.6 groovy-all in
>> jmeter
>> >> > tomorrow evening.
>> >> >
>> >> > Regards
>> >> > Philippe
>> >> >
>> >> > On Thu, Feb 25, 2016 at 3:53 AM, Vladimir Sitnikov <
>> >> > sitnikov.vladimir@gmail.com <javascript:;> <javascript:;>> wrote:
>> >> >
>> >> >> TL;DR: +1 for bundling proper groovy.jar with JMeter.
>> >> >>
>> >> >> Alternative approach would be some kind of "online store to download
>> >> >> JMeter plugins". I am not sure if that can be done in a reasonable
>> >> >> time frame though.
>> >> >>
>> >> >> In my opinion, there are number of advantages for bundling Groovy:
>> >> >> 1) I can easily get a "online groovy console", so I can easily check
>> >> >> if -3.abs() returns 3 or -3. That is exactly JMeter users have to do.
>> >> >> JMeter (as IDE) does not provide ability to execute small parts of
>> >> >> code, thus users have to use their minds (or Google or whatever) to
>> >> >> craft code that works. I claim using Groovy online console helps a
>> >> >> lot. With BeanShell you never know if your code will work until you
>> >> >> run it.
>> >> >>
>> >> >> groovyconsole.appspot.com just blows BeanShell out of the water.
>> >> >>
>> >> >> 2) "Groovy is in active development, thus everybody would have to
>> >> >> constantly update groovy.jar anyway" is not justified.
>> >> >> Even though there will be new groovy.jar releases, it is unlikely
>> >> >> users will use cutting-edge features of Groovy language in JMeter
>> >> >> scenarios.
>> >> >>
>> >> >> I think the main usage would be just regular boilerplate code, so
>> >> >> non-experts would never be able to write Groovy code that requires
>> the
>> >> >> latest groovy.jar to execute.
>> >> >>
>> >> >> 3) Even though I prefer not to use Groovy, I see no better
>> replacement
>> >> >> for glue code in JMeter's samplers. In fact, it could even make sense
>> >> >> to add a menu entry like "create groovy samlper". That way users
>> could
>> >> >> access it without secret knowledge of what JSR223 means.
>> >> >>
>> >> >> 4) Groovy's Java interop is much better designed from language point
>> >> >> of view than the one of JavaScript. I mean it is just much easier to
>> >> >> call java libraries since that was considered by Groovy language
>> >> >> designers. This somewhat rules out JavaScript. BeanShell is too
>> >> >> verbose and it does not seem to be the right tool as a glue language.
>> >> >>
>> >> >> As a Java programmer, I'm much more fluent in "Groovy+groovyconsole"
>> >> >> than in "BeanShell+no_way_to_validate_snippet".
>> >> >> I'm fluent in JavaScript, yet it does not help me to answer "how to
>> >> >> read/write a file". Rhino/Nashorn have java interop, yet it is not in
>> >> >> my active vocabulary, thus I would prefer groovy.
>> >> >>
>> >> >> 5) It is a bit hard to pick the proper groovy jar.
>> >> >>
>> >> >> 6) At the end of the day, "valid java code is valid Groovy code"
>> >> >>
>> >> >> 7) Having Groovy in JMeter would add nice "backward compatibility"
>> >> >> feature. Suppose JMeter 3.0 includes Groovy. Then load scripts would
>> >> >> work in exactly the same way for all the users of JMeter 3.0. If
>> >> >> everybody downloads his/her own version of Groovy, that would easily
>> >> >> result in "JMeter script broken for unknown reason" or even "wrong
>> >> >> results due to newer/incompatible groovy.jar version".
>> >> >>
>> >> >>
>> >> >> sebb> The only advantage I can see is that JMeter users don't have to
>> >> >> sebb> download Groovy in order to use it.
>> >> >>
>> >> >> That is huge advantage.
>> >> >> Current http://groovy-lang.org/download.html is not designed for
>> >> >> downloading a single jar file.
>> >> >> "apache-groovy-binary...zip" is 35MiB zip file with lots of jars
>> >> >> inside. Technically speaking, 52 of them start with "groovy-"
>> >> >> I do not want to learn/read which groovy jar I need. I just want to
>> >> >> make JMeter work.
>> >> >>
>> >> >> Milamber>2/ Why Beanshell is including in JMeter and not Groovy?
>> >> >>
>> >> >> I think it might be a good time to deprecate BeanShell. Not in a
>> sense
>> >> >> "remove it in the subsequent release", but in order to clean up
>> menus,
>> >> >> etc, etc. One never has excessive screen space, so removing BeanShell
>> >> >> menus seems wise from my point of view.
>> >> >>
>> >> >>
>> >> >> sebb> This adds aboiut 5% to the total jar size.
>> >> >>
>> >> >> That is OK from my point of view.
>> >> >>
>> >> >> Current apache-jmeter-2.13.zip includes:
>> >> >> 1) Lots of javadocs (docs/api). 46MiB when unzipped. That is more
>> than
>> >> >> 50% of the JMeter (82MiB is the net volume of unzipped JMeter 2.13).
>> >> >> If removing docs/api, the zip file takes 5MiB less. I'm not sure
>> >> >> javadocs need be the part of regular JMeter binary zip.
>> >> >>
>> >> >> 2) Current docs/images/screenshots takes 12MiB. It can likely be fit
>> >> >> under 5MiB (~save 10MiB) if crunched through a png optimizer.
>> >> >>
>> >> >> Vladimir
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Cordialement.
>> >> > Philippe Mouawad.
>> >>
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: About including Groovy
Posted by Philippe Mouawad <ph...@gmail.com>.
On Thursday, March 3, 2016, sebb <se...@gmail.com> wrote:
> On 3 March 2016 at 06:37, Philippe Mouawad <philippe.mouawad@gmail.com
> <javascript:;>> wrote:
> > On Thursday, March 3, 2016, sebb <sebbaz@gmail.com <javascript:;>>
> wrote:
> >
> >> On 2 March 2016 at 22:06, Philippe Mouawad <philippe.mouawad@gmail.com
> <javascript:;>
> >> <javascript:;>> wrote:
> >> > Hello,
> >> > For information , we had a vote on our twitter account:
> >> > - https://twitter.com/apachejmeter/status/702590631571496961
> >> >
> >> > Results are the following:
> >> > Participation : 100 Votes
> >> > - 9% NO
> >>
> >> What reasons were given for saying no?
> >
> >
> > People don't give an explanation for their vote on twitter.
> > But you can read by clicking on the link above the replies to the voting
> > tweet to see 2 or 3 reasons for no and the same for yes.
>
> I only see 6 votes there; the proportions are 50-50.
> All the No votes are about keeping JMeter light-weight.
>
> There does not seem to be a way to see the other votes.
you're mixing votes and replies to tweets.
Vote give 91%
Besides in this thread, majority of comments are for a bundling.
But if you want we can start a technical vote on this although I think it's
a lot of energy spent.
>
> >>
> >> > - 91% YES
> >> >
> >> >
> >> > This has no particular value except to give a kind of feeling about
> it.
> >> >
> >> > From this discussion it appears we have a move towards including it.
> >> >
> >> > Unless there is a NOGO I will start bundling 2.4.6 groovy-all in
> jmeter
> >> > tomorrow evening.
> >> >
> >> > Regards
> >> > Philippe
> >> >
> >> > On Thu, Feb 25, 2016 at 3:53 AM, Vladimir Sitnikov <
> >> > sitnikov.vladimir@gmail.com <javascript:;> <javascript:;>> wrote:
> >> >
> >> >> TL;DR: +1 for bundling proper groovy.jar with JMeter.
> >> >>
> >> >> Alternative approach would be some kind of "online store to download
> >> >> JMeter plugins". I am not sure if that can be done in a reasonable
> >> >> time frame though.
> >> >>
> >> >> In my opinion, there are number of advantages for bundling Groovy:
> >> >> 1) I can easily get a "online groovy console", so I can easily check
> >> >> if -3.abs() returns 3 or -3. That is exactly JMeter users have to do.
> >> >> JMeter (as IDE) does not provide ability to execute small parts of
> >> >> code, thus users have to use their minds (or Google or whatever) to
> >> >> craft code that works. I claim using Groovy online console helps a
> >> >> lot. With BeanShell you never know if your code will work until you
> >> >> run it.
> >> >>
> >> >> groovyconsole.appspot.com just blows BeanShell out of the water.
> >> >>
> >> >> 2) "Groovy is in active development, thus everybody would have to
> >> >> constantly update groovy.jar anyway" is not justified.
> >> >> Even though there will be new groovy.jar releases, it is unlikely
> >> >> users will use cutting-edge features of Groovy language in JMeter
> >> >> scenarios.
> >> >>
> >> >> I think the main usage would be just regular boilerplate code, so
> >> >> non-experts would never be able to write Groovy code that requires
> the
> >> >> latest groovy.jar to execute.
> >> >>
> >> >> 3) Even though I prefer not to use Groovy, I see no better
> replacement
> >> >> for glue code in JMeter's samplers. In fact, it could even make sense
> >> >> to add a menu entry like "create groovy samlper". That way users
> could
> >> >> access it without secret knowledge of what JSR223 means.
> >> >>
> >> >> 4) Groovy's Java interop is much better designed from language point
> >> >> of view than the one of JavaScript. I mean it is just much easier to
> >> >> call java libraries since that was considered by Groovy language
> >> >> designers. This somewhat rules out JavaScript. BeanShell is too
> >> >> verbose and it does not seem to be the right tool as a glue language.
> >> >>
> >> >> As a Java programmer, I'm much more fluent in "Groovy+groovyconsole"
> >> >> than in "BeanShell+no_way_to_validate_snippet".
> >> >> I'm fluent in JavaScript, yet it does not help me to answer "how to
> >> >> read/write a file". Rhino/Nashorn have java interop, yet it is not in
> >> >> my active vocabulary, thus I would prefer groovy.
> >> >>
> >> >> 5) It is a bit hard to pick the proper groovy jar.
> >> >>
> >> >> 6) At the end of the day, "valid java code is valid Groovy code"
> >> >>
> >> >> 7) Having Groovy in JMeter would add nice "backward compatibility"
> >> >> feature. Suppose JMeter 3.0 includes Groovy. Then load scripts would
> >> >> work in exactly the same way for all the users of JMeter 3.0. If
> >> >> everybody downloads his/her own version of Groovy, that would easily
> >> >> result in "JMeter script broken for unknown reason" or even "wrong
> >> >> results due to newer/incompatible groovy.jar version".
> >> >>
> >> >>
> >> >> sebb> The only advantage I can see is that JMeter users don't have to
> >> >> sebb> download Groovy in order to use it.
> >> >>
> >> >> That is huge advantage.
> >> >> Current http://groovy-lang.org/download.html is not designed for
> >> >> downloading a single jar file.
> >> >> "apache-groovy-binary...zip" is 35MiB zip file with lots of jars
> >> >> inside. Technically speaking, 52 of them start with "groovy-"
> >> >> I do not want to learn/read which groovy jar I need. I just want to
> >> >> make JMeter work.
> >> >>
> >> >> Milamber>2/ Why Beanshell is including in JMeter and not Groovy?
> >> >>
> >> >> I think it might be a good time to deprecate BeanShell. Not in a
> sense
> >> >> "remove it in the subsequent release", but in order to clean up
> menus,
> >> >> etc, etc. One never has excessive screen space, so removing BeanShell
> >> >> menus seems wise from my point of view.
> >> >>
> >> >>
> >> >> sebb> This adds aboiut 5% to the total jar size.
> >> >>
> >> >> That is OK from my point of view.
> >> >>
> >> >> Current apache-jmeter-2.13.zip includes:
> >> >> 1) Lots of javadocs (docs/api). 46MiB when unzipped. That is more
> than
> >> >> 50% of the JMeter (82MiB is the net volume of unzipped JMeter 2.13).
> >> >> If removing docs/api, the zip file takes 5MiB less. I'm not sure
> >> >> javadocs need be the part of regular JMeter binary zip.
> >> >>
> >> >> 2) Current docs/images/screenshots takes 12MiB. It can likely be fit
> >> >> under 5MiB (~save 10MiB) if crunched through a png optimizer.
> >> >>
> >> >> Vladimir
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Cordialement.
> >> > Philippe Mouawad.
> >>
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>
--
Cordialement.
Philippe Mouawad.
Re: About including Groovy
Posted by sebb <se...@gmail.com>.
On 3 March 2016 at 06:37, Philippe Mouawad <ph...@gmail.com> wrote:
> On Thursday, March 3, 2016, sebb <se...@gmail.com> wrote:
>
>> On 2 March 2016 at 22:06, Philippe Mouawad <philippe.mouawad@gmail.com
>> <javascript:;>> wrote:
>> > Hello,
>> > For information , we had a vote on our twitter account:
>> > - https://twitter.com/apachejmeter/status/702590631571496961
>> >
>> > Results are the following:
>> > Participation : 100 Votes
>> > - 9% NO
>>
>> What reasons were given for saying no?
>
>
> People don't give an explanation for their vote on twitter.
> But you can read by clicking on the link above the replies to the voting
> tweet to see 2 or 3 reasons for no and the same for yes.
I only see 6 votes there; the proportions are 50-50.
All the No votes are about keeping JMeter light-weight.
There does not seem to be a way to see the other votes.
>>
>> > - 91% YES
>> >
>> >
>> > This has no particular value except to give a kind of feeling about it.
>> >
>> > From this discussion it appears we have a move towards including it.
>> >
>> > Unless there is a NOGO I will start bundling 2.4.6 groovy-all in jmeter
>> > tomorrow evening.
>> >
>> > Regards
>> > Philippe
>> >
>> > On Thu, Feb 25, 2016 at 3:53 AM, Vladimir Sitnikov <
>> > sitnikov.vladimir@gmail.com <javascript:;>> wrote:
>> >
>> >> TL;DR: +1 for bundling proper groovy.jar with JMeter.
>> >>
>> >> Alternative approach would be some kind of "online store to download
>> >> JMeter plugins". I am not sure if that can be done in a reasonable
>> >> time frame though.
>> >>
>> >> In my opinion, there are number of advantages for bundling Groovy:
>> >> 1) I can easily get a "online groovy console", so I can easily check
>> >> if -3.abs() returns 3 or -3. That is exactly JMeter users have to do.
>> >> JMeter (as IDE) does not provide ability to execute small parts of
>> >> code, thus users have to use their minds (or Google or whatever) to
>> >> craft code that works. I claim using Groovy online console helps a
>> >> lot. With BeanShell you never know if your code will work until you
>> >> run it.
>> >>
>> >> groovyconsole.appspot.com just blows BeanShell out of the water.
>> >>
>> >> 2) "Groovy is in active development, thus everybody would have to
>> >> constantly update groovy.jar anyway" is not justified.
>> >> Even though there will be new groovy.jar releases, it is unlikely
>> >> users will use cutting-edge features of Groovy language in JMeter
>> >> scenarios.
>> >>
>> >> I think the main usage would be just regular boilerplate code, so
>> >> non-experts would never be able to write Groovy code that requires the
>> >> latest groovy.jar to execute.
>> >>
>> >> 3) Even though I prefer not to use Groovy, I see no better replacement
>> >> for glue code in JMeter's samplers. In fact, it could even make sense
>> >> to add a menu entry like "create groovy samlper". That way users could
>> >> access it without secret knowledge of what JSR223 means.
>> >>
>> >> 4) Groovy's Java interop is much better designed from language point
>> >> of view than the one of JavaScript. I mean it is just much easier to
>> >> call java libraries since that was considered by Groovy language
>> >> designers. This somewhat rules out JavaScript. BeanShell is too
>> >> verbose and it does not seem to be the right tool as a glue language.
>> >>
>> >> As a Java programmer, I'm much more fluent in "Groovy+groovyconsole"
>> >> than in "BeanShell+no_way_to_validate_snippet".
>> >> I'm fluent in JavaScript, yet it does not help me to answer "how to
>> >> read/write a file". Rhino/Nashorn have java interop, yet it is not in
>> >> my active vocabulary, thus I would prefer groovy.
>> >>
>> >> 5) It is a bit hard to pick the proper groovy jar.
>> >>
>> >> 6) At the end of the day, "valid java code is valid Groovy code"
>> >>
>> >> 7) Having Groovy in JMeter would add nice "backward compatibility"
>> >> feature. Suppose JMeter 3.0 includes Groovy. Then load scripts would
>> >> work in exactly the same way for all the users of JMeter 3.0. If
>> >> everybody downloads his/her own version of Groovy, that would easily
>> >> result in "JMeter script broken for unknown reason" or even "wrong
>> >> results due to newer/incompatible groovy.jar version".
>> >>
>> >>
>> >> sebb> The only advantage I can see is that JMeter users don't have to
>> >> sebb> download Groovy in order to use it.
>> >>
>> >> That is huge advantage.
>> >> Current http://groovy-lang.org/download.html is not designed for
>> >> downloading a single jar file.
>> >> "apache-groovy-binary...zip" is 35MiB zip file with lots of jars
>> >> inside. Technically speaking, 52 of them start with "groovy-"
>> >> I do not want to learn/read which groovy jar I need. I just want to
>> >> make JMeter work.
>> >>
>> >> Milamber>2/ Why Beanshell is including in JMeter and not Groovy?
>> >>
>> >> I think it might be a good time to deprecate BeanShell. Not in a sense
>> >> "remove it in the subsequent release", but in order to clean up menus,
>> >> etc, etc. One never has excessive screen space, so removing BeanShell
>> >> menus seems wise from my point of view.
>> >>
>> >>
>> >> sebb> This adds aboiut 5% to the total jar size.
>> >>
>> >> That is OK from my point of view.
>> >>
>> >> Current apache-jmeter-2.13.zip includes:
>> >> 1) Lots of javadocs (docs/api). 46MiB when unzipped. That is more than
>> >> 50% of the JMeter (82MiB is the net volume of unzipped JMeter 2.13).
>> >> If removing docs/api, the zip file takes 5MiB less. I'm not sure
>> >> javadocs need be the part of regular JMeter binary zip.
>> >>
>> >> 2) Current docs/images/screenshots takes 12MiB. It can likely be fit
>> >> under 5MiB (~save 10MiB) if crunched through a png optimizer.
>> >>
>> >> Vladimir
>> >>
>> >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: About including Groovy
Posted by Philippe Mouawad <ph...@gmail.com>.
On Thursday, March 3, 2016, sebb <se...@gmail.com> wrote:
> On 2 March 2016 at 22:06, Philippe Mouawad <philippe.mouawad@gmail.com
> <javascript:;>> wrote:
> > Hello,
> > For information , we had a vote on our twitter account:
> > - https://twitter.com/apachejmeter/status/702590631571496961
> >
> > Results are the following:
> > Participation : 100 Votes
> > - 9% NO
>
> What reasons were given for saying no?
People don't give an explanation for their vote on twitter.
But you can read by clicking on the link above the replies to the voting
tweet to see 2 or 3 reasons for no and the same for yes.
>
> > - 91% YES
> >
> >
> > This has no particular value except to give a kind of feeling about it.
> >
> > From this discussion it appears we have a move towards including it.
> >
> > Unless there is a NOGO I will start bundling 2.4.6 groovy-all in jmeter
> > tomorrow evening.
> >
> > Regards
> > Philippe
> >
> > On Thu, Feb 25, 2016 at 3:53 AM, Vladimir Sitnikov <
> > sitnikov.vladimir@gmail.com <javascript:;>> wrote:
> >
> >> TL;DR: +1 for bundling proper groovy.jar with JMeter.
> >>
> >> Alternative approach would be some kind of "online store to download
> >> JMeter plugins". I am not sure if that can be done in a reasonable
> >> time frame though.
> >>
> >> In my opinion, there are number of advantages for bundling Groovy:
> >> 1) I can easily get a "online groovy console", so I can easily check
> >> if -3.abs() returns 3 or -3. That is exactly JMeter users have to do.
> >> JMeter (as IDE) does not provide ability to execute small parts of
> >> code, thus users have to use their minds (or Google or whatever) to
> >> craft code that works. I claim using Groovy online console helps a
> >> lot. With BeanShell you never know if your code will work until you
> >> run it.
> >>
> >> groovyconsole.appspot.com just blows BeanShell out of the water.
> >>
> >> 2) "Groovy is in active development, thus everybody would have to
> >> constantly update groovy.jar anyway" is not justified.
> >> Even though there will be new groovy.jar releases, it is unlikely
> >> users will use cutting-edge features of Groovy language in JMeter
> >> scenarios.
> >>
> >> I think the main usage would be just regular boilerplate code, so
> >> non-experts would never be able to write Groovy code that requires the
> >> latest groovy.jar to execute.
> >>
> >> 3) Even though I prefer not to use Groovy, I see no better replacement
> >> for glue code in JMeter's samplers. In fact, it could even make sense
> >> to add a menu entry like "create groovy samlper". That way users could
> >> access it without secret knowledge of what JSR223 means.
> >>
> >> 4) Groovy's Java interop is much better designed from language point
> >> of view than the one of JavaScript. I mean it is just much easier to
> >> call java libraries since that was considered by Groovy language
> >> designers. This somewhat rules out JavaScript. BeanShell is too
> >> verbose and it does not seem to be the right tool as a glue language.
> >>
> >> As a Java programmer, I'm much more fluent in "Groovy+groovyconsole"
> >> than in "BeanShell+no_way_to_validate_snippet".
> >> I'm fluent in JavaScript, yet it does not help me to answer "how to
> >> read/write a file". Rhino/Nashorn have java interop, yet it is not in
> >> my active vocabulary, thus I would prefer groovy.
> >>
> >> 5) It is a bit hard to pick the proper groovy jar.
> >>
> >> 6) At the end of the day, "valid java code is valid Groovy code"
> >>
> >> 7) Having Groovy in JMeter would add nice "backward compatibility"
> >> feature. Suppose JMeter 3.0 includes Groovy. Then load scripts would
> >> work in exactly the same way for all the users of JMeter 3.0. If
> >> everybody downloads his/her own version of Groovy, that would easily
> >> result in "JMeter script broken for unknown reason" or even "wrong
> >> results due to newer/incompatible groovy.jar version".
> >>
> >>
> >> sebb> The only advantage I can see is that JMeter users don't have to
> >> sebb> download Groovy in order to use it.
> >>
> >> That is huge advantage.
> >> Current http://groovy-lang.org/download.html is not designed for
> >> downloading a single jar file.
> >> "apache-groovy-binary...zip" is 35MiB zip file with lots of jars
> >> inside. Technically speaking, 52 of them start with "groovy-"
> >> I do not want to learn/read which groovy jar I need. I just want to
> >> make JMeter work.
> >>
> >> Milamber>2/ Why Beanshell is including in JMeter and not Groovy?
> >>
> >> I think it might be a good time to deprecate BeanShell. Not in a sense
> >> "remove it in the subsequent release", but in order to clean up menus,
> >> etc, etc. One never has excessive screen space, so removing BeanShell
> >> menus seems wise from my point of view.
> >>
> >>
> >> sebb> This adds aboiut 5% to the total jar size.
> >>
> >> That is OK from my point of view.
> >>
> >> Current apache-jmeter-2.13.zip includes:
> >> 1) Lots of javadocs (docs/api). 46MiB when unzipped. That is more than
> >> 50% of the JMeter (82MiB is the net volume of unzipped JMeter 2.13).
> >> If removing docs/api, the zip file takes 5MiB less. I'm not sure
> >> javadocs need be the part of regular JMeter binary zip.
> >>
> >> 2) Current docs/images/screenshots takes 12MiB. It can likely be fit
> >> under 5MiB (~save 10MiB) if crunched through a png optimizer.
> >>
> >> Vladimir
> >>
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>
--
Cordialement.
Philippe Mouawad.
Re: About including Groovy
Posted by sebb <se...@gmail.com>.
On 2 March 2016 at 22:06, Philippe Mouawad <ph...@gmail.com> wrote:
> Hello,
> For information , we had a vote on our twitter account:
> - https://twitter.com/apachejmeter/status/702590631571496961
>
> Results are the following:
> Participation : 100 Votes
> - 9% NO
What reasons were given for saying no?
> - 91% YES
>
>
> This has no particular value except to give a kind of feeling about it.
>
> From this discussion it appears we have a move towards including it.
>
> Unless there is a NOGO I will start bundling 2.4.6 groovy-all in jmeter
> tomorrow evening.
>
> Regards
> Philippe
>
> On Thu, Feb 25, 2016 at 3:53 AM, Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
>
>> TL;DR: +1 for bundling proper groovy.jar with JMeter.
>>
>> Alternative approach would be some kind of "online store to download
>> JMeter plugins". I am not sure if that can be done in a reasonable
>> time frame though.
>>
>> In my opinion, there are number of advantages for bundling Groovy:
>> 1) I can easily get a "online groovy console", so I can easily check
>> if -3.abs() returns 3 or -3. That is exactly JMeter users have to do.
>> JMeter (as IDE) does not provide ability to execute small parts of
>> code, thus users have to use their minds (or Google or whatever) to
>> craft code that works. I claim using Groovy online console helps a
>> lot. With BeanShell you never know if your code will work until you
>> run it.
>>
>> groovyconsole.appspot.com just blows BeanShell out of the water.
>>
>> 2) "Groovy is in active development, thus everybody would have to
>> constantly update groovy.jar anyway" is not justified.
>> Even though there will be new groovy.jar releases, it is unlikely
>> users will use cutting-edge features of Groovy language in JMeter
>> scenarios.
>>
>> I think the main usage would be just regular boilerplate code, so
>> non-experts would never be able to write Groovy code that requires the
>> latest groovy.jar to execute.
>>
>> 3) Even though I prefer not to use Groovy, I see no better replacement
>> for glue code in JMeter's samplers. In fact, it could even make sense
>> to add a menu entry like "create groovy samlper". That way users could
>> access it without secret knowledge of what JSR223 means.
>>
>> 4) Groovy's Java interop is much better designed from language point
>> of view than the one of JavaScript. I mean it is just much easier to
>> call java libraries since that was considered by Groovy language
>> designers. This somewhat rules out JavaScript. BeanShell is too
>> verbose and it does not seem to be the right tool as a glue language.
>>
>> As a Java programmer, I'm much more fluent in "Groovy+groovyconsole"
>> than in "BeanShell+no_way_to_validate_snippet".
>> I'm fluent in JavaScript, yet it does not help me to answer "how to
>> read/write a file". Rhino/Nashorn have java interop, yet it is not in
>> my active vocabulary, thus I would prefer groovy.
>>
>> 5) It is a bit hard to pick the proper groovy jar.
>>
>> 6) At the end of the day, "valid java code is valid Groovy code"
>>
>> 7) Having Groovy in JMeter would add nice "backward compatibility"
>> feature. Suppose JMeter 3.0 includes Groovy. Then load scripts would
>> work in exactly the same way for all the users of JMeter 3.0. If
>> everybody downloads his/her own version of Groovy, that would easily
>> result in "JMeter script broken for unknown reason" or even "wrong
>> results due to newer/incompatible groovy.jar version".
>>
>>
>> sebb> The only advantage I can see is that JMeter users don't have to
>> sebb> download Groovy in order to use it.
>>
>> That is huge advantage.
>> Current http://groovy-lang.org/download.html is not designed for
>> downloading a single jar file.
>> "apache-groovy-binary...zip" is 35MiB zip file with lots of jars
>> inside. Technically speaking, 52 of them start with "groovy-"
>> I do not want to learn/read which groovy jar I need. I just want to
>> make JMeter work.
>>
>> Milamber>2/ Why Beanshell is including in JMeter and not Groovy?
>>
>> I think it might be a good time to deprecate BeanShell. Not in a sense
>> "remove it in the subsequent release", but in order to clean up menus,
>> etc, etc. One never has excessive screen space, so removing BeanShell
>> menus seems wise from my point of view.
>>
>>
>> sebb> This adds aboiut 5% to the total jar size.
>>
>> That is OK from my point of view.
>>
>> Current apache-jmeter-2.13.zip includes:
>> 1) Lots of javadocs (docs/api). 46MiB when unzipped. That is more than
>> 50% of the JMeter (82MiB is the net volume of unzipped JMeter 2.13).
>> If removing docs/api, the zip file takes 5MiB less. I'm not sure
>> javadocs need be the part of regular JMeter binary zip.
>>
>> 2) Current docs/images/screenshots takes 12MiB. It can likely be fit
>> under 5MiB (~save 10MiB) if crunched through a png optimizer.
>>
>> Vladimir
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.