Mailing-List: contact dev-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jmeter.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAB=Je-Fth98w5=784jWADGdZ2nBCS2yDeWVn0FEA0VXS51ZAXA@mail.gmail.com>
References: <56CB5A53.1090506@gmx.net>
	<CAH9fUpb00Q_rtGHaisDsHHHATQRfC64LkLEJYrYyt3Jxk6=oRA@mail.gmail.com>
	<56CC2C68.1090701@apache.org>
	<CAOGo0VYrvEoRETYRQodeUfywhWnK=Q88+2qqNEGvuK8cCVKiaw@mail.gmail.com>
	<56CE4503.3030203@apache.org>
	<CAB=Je-Fth98w5=784jWADGdZ2nBCS2yDeWVn0FEA0VXS51ZAXA@mail.gmail.com>
Date: Wed, 2 Mar 2016 23:06:07 +0100
Message-ID: 
 <CAH9fUpYvfQf4iTax91wD-4uLzgyD92P9Rr--wf+HCELqyCFvKw@mail.gmail.com>
Subject: Re: About including Groovy
From: Philippe Mouawad <philippe.mouawad@gmail.com>
To: "dev@jmeter.apache.org" <dev@jmeter.apache.org>
Content-Type: multipart/alternative; boundary=001a1138f268c27296052d1816ab

--001a1138f268c27296052d1816ab
Content-Type: text/plain; charset=UTF-8

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.

--001a1138f268c27296052d1816ab--