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
