jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: About including Groovy
Date Thu, 03 Mar 2016 06:37:11 GMT
On Thursday, March 3, 2016, sebb <sebbaz@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message