Re: Implemented groovy support for scripting

Hi Ryan,

This looks good, well done!

I'd like to see this develop on its own a little before pulling it into
mainline. I need to have time to review it, but a few immediate
thoughts: there needs to be some documentation, it needs to pass
checkstyle, and I'd like it to separate it from the core module.

Can you first separate it out from grinder-core as a separate mvn
module/jar? This has a couple of benefits: firstly it makes it easier to
review, and secondly if you do this, there's no immediate reason to
merge. Others can use it with the standard grinder by adding it to the
start of the classpath.

Also, to get it into mainline, I'd want focussed patches rather than a
pull-request. E.g. I note that there's recently been a non-related
change to your repository to introduce Jython 2.5.2 as a test
dependency. While the current mvn management of alternative Jython
implementations is hacky (partly due to the Jython versions not being in
mvn central), its not right to make Jython a top level test dependency.
Anyway - you get the point, I don't want to pull in a set of unrelated
changes.

Anyway, good work,

- Phil



On 28/06/12 05:41, Ryan Gardner wrote:
> Grinder's recent addition of clojure made it very easy to implement
> support for Groovy. 
>
> I have a branch that I put on my github account with the groovy
> support, a basic "hello world" example, and unit tests around the
> GroovyScriptEngine 
>
> The only convention that is enforced is that the groovy script must be
> a class, and it must define a closure named "testRunner" - (this
> convention is based on the convention used for the Jython scripts, and
> adapted to the groovy-style camel case for closure names)
>
> The work is here - 
>
> https://github.com/ryangardner/grinder/tree/groovy-script-engine
>
> This is just my first crack at it, I am going to tinker with it and
> may end up doing things differently (I might move away from pulling
> the closure out and getting a callable and instead use the
> GroovyObject "invokeMethod" on the script if it performs better). 
>
> I'm open to any comments about the implementation - I can clean it up
> and then submit it to you to be merged in if you are interested.
>
> As far as performance is concerned, when using Groovy 2.0's
> @CompileStatic transformation the performance is comparable to the
> Jython script engine for testing the Hello World logging (around 80000
> TPS on my machine when running with 10 threads). BUt when using a
> normal dynamic groovy without static compilation it seems limited to
> about 17000 TPS on my machine with 10 threads.
>
> I can provide a set of sample scripts for groovy and also provide some
> additional documentation to go along with it. As of now I have only
> tested a few basic scripts, but I expect it should work pretty nicely
> with the existing grinder plugins and code. 
>
> Ryan
>


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/