On Thu, Feb 25, 2016 at 1:52 AM, sebb <[email protected]> wrote: > On 24 February 2016 at 14:21, Philippe Mouawad > <[email protected]> wrote: > > On Wed, Feb 24, 2016 at 1:04 PM, sebb <[email protected]> wrote: > > > >> Let's be clear what this discussion is about. > >> > >> JMeter already supports Groovy. > >> It's not a question of whether Groovy is a good scripting language. > >> > >> The question is whether or not to bundle Groovy with JMeter. > >> > >> The only advantage I can see is that JMeter users don't have to > >> download Groovy in order to use it. > >> > > > > I don't share your opinion. > > Take the beginner who downloads JMeter, to use Groovy, he must be aware > > that it is available through JSR223 AND that he must download (the > correct > > Groovy Jar, put it in the correct folder, restart JMeter). > > This is exactly the advantage I quoted; it does not add a new argument. > > > Meanwhile he can > > screw an existing test plan that used Groovy when he migrates to a new > > JMeter that does not have Groovy. > > If he created the plan that uses Groovy, then clearly he already has it. >
If he created the plan that uses Groovy, then clearly he is aware that Groovy is a supported option for a JSR223 sampler/procesor/what have you. He may not be aware that Groovy (unlike Beanshell) does not currently come bundled with JMeter. > > If it is a 3rd party plan then they ought to document that it uses Groovy. > > > So he selects this element and doesn't find it. Do you think he will go > > further or will he use Beanshell ? (and then face all JAVA 6, 7 , 8 > issues > > with Beanshell ) > > Read all the blogs on JMeter and you will see how many users still use > > Beanshell because they are not aware of Groovy or they were not able to > > set it up. > > Documentation is the answer here. > No. Intuitive design is the answer here. It means you spend less time maintaining the documentation, and less time fielding questions from clueless newbies who couldn't be bothered to read it. > > > Why make it harder for a beginner through and even for experts to use > > Groovy instead of just distributing it ? > > Because distribution has disadvantages. > > Groovy is an Apache project ? Why not use it > > Groovy is sexy, useful and sustainable, why be so reluctant with it ? > > Again, that is not the question. > > > > >> The disadvantages are: > >> - additional download size, even if Groovy is not needed > >> > > Groovy add 7mb to bundle , is this an issue nowadays ? I don't think so > > > >> - users will still have to download Groovy if there is a new version > >> > > That's the same problem as with any of our jars in lib. > > But Groovy is likely to be changing more rapidly, and adding new features. > Most of the other jars change rarely, and JMeter generally makes use > of part of them. > So there is less need to update them. > Groovy is likely to be changing more rapidly than other jars because it's still under active development, unlike many of the jars currently distributed with JMeter. This is a good thing. JMeter PMC is still free to decide how often they want to update the dependency, but they can do so based on user feedback (bugzilla and mailing lists). > > > > > > > > >> and JMeter has not yet been updated. > >> > >> It would be useful to know: > >> - what jars are needed? > >> > > groovy-all-2.4.5.jar > > Latest version is 2.4.6 > > > > > >> - how large are they? > >> > >> 7mb > > > > i.e. about twice the size of the largest jar. > > This adds aboiut 5% to the total jar size. > The JMeter 2.13 release tarball is 33.7MB in size. The zip version is 35.9MB. You add 6.5% to the total download size by choosing the zip version over the tarball. > > >> An alternative approach would be to provide a script to download Groovy. > >> This would solve both the disadvantages I mention. > >> > > > > Again another external script, + documentation + users aware of it > > > > > >> > >> We could even perhaps provide a template to download Groovy using > JMeter. > >> > > > > In my opinion, too complex , more work for us, more work for user > > > > This could be a useful sample for people to try. > >> > > > > I am waiting for other members opinion on this. > > > >> > >> > >> On 23 February 2016 at 09:54, Milamber <[email protected]> wrote: > >> > > >> > I think that is a very good idea to add Groovy to JMeter. > >> > > >> > > >> > On 22/02/2016 19:05, Philippe Mouawad wrote: > >> >> > >> >> Hello, > >> >> +1 for integration as of me. > >> >> Reasons: > >> >> - Make user experience as simple as possible (no need to bundle > >> additional > >> >> libraries and manage configuration > >> >> -jsr223+groovy is the most performing option compared to beanshell > >> >> - as of the scripting I had to do, I always had at some step to > script > >> and > >> >> used this combination > >> >> - beanshell does not support java6/7/8 sugar syntax > >> >> - groovy is an easy scripting language with the full power of java + > a > >> lot > >> >> of additional features for xml, json manipulation, jmx ... > >> >> - Groovy is now Apache :) > >> >> > >> >> > >> >> > >> >> > >> >> Regards > >> >> > >> >> On Monday, February 22, 2016, Pascal Schumacher < > >> [email protected]> > >> >> wrote: > >> >> > >> >>> Hi all, > >> >>> > >> >>> when this was last discussed, it was decided to wait till there is > >> >>> official Apache release (outside of Apache Incubator) of Groovy. > Groovy > >> >>> 2.4.6 is the first release as a top level project and it was just > >> >>> released: > >> >>> > >> >>> > >> > http://mail-archives.apache.org/mod_mbox/groovy-users/201602.mbox/%3CCADQzvmnMENGU17_%3D9-_%3DnPDn9Ob3QsXC9iJHChT_zAWo0-CHJg%40mail.gmail.com%3E > >> >>> > >> >>> Cheers, > >> >>> Pascal > >> >>> > >> >> > >> > > >> > > > > > > > > -- > > Cordialement. > > Philippe Mouawad. >
