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 Fri, 04 Mar 2016 06:41:46 GMT
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 <sebbaz@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.

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