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 <[email protected]> wrote: > On 3 March 2016 at 11:31, Philippe Mouawad <[email protected] > <javascript:;>> wrote: > > On Thursday, March 3, 2016, sebb <[email protected] <javascript:;>> > wrote: > > > >> On 3 March 2016 at 06:37, Philippe Mouawad <[email protected] > <javascript:;> > >> <javascript:;>> wrote: > >> > On Thursday, March 3, 2016, sebb <[email protected] <javascript:;> > <javascript:;>> > >> wrote: > >> > > >> >> On 2 March 2016 at 22:06, Philippe Mouawad < > [email protected] <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 < > >> >> > [email protected] <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.
