For a long time I’ve been meaning to rewrite the “groovy runner” plugin so that groovy wasn’t a requirement, and having found myself with some unexpected but welcome time on my hands I have finally done so.
Usage is the same as for groovy… a number of variables are available within the script without being retrieved, principally an “Issue” and transientVars, which is a Map containing useful stuff pertinent to the workflow transition.
I am interested in trying to make it easier to prototype and write calculated custom fields, portlets and reports. A script would run providing variables to a velocity template, but equally it could be to a GSP (GroovyServer page), or to some other template engine. The key thing is that no restart would be required.
Several people have asked if this plugin can be used for listeners. Well, not really, for a similar reason as above. With an issue listener you would normally implement com.atlassian.jira.event.issue.IssueEventListener. So where would the script be run, on issueAssigned, or issueResolved etc? Having separate scripts for each extension point would be impossible to maintain.
However you can use groovy, or anything that will compile to a .class file such as jruby, and IMHO you will get the same productivity benefits. The additional hurdle that you face is that you must compile your groovy class.
The simplest way to set yourself up is by following the instructions for getting a dev environment with JIRA and IDEA, here.
Then, download the DebugListener sample file. This is a java class but you can rename it .groovy, and it will compile as valid groovy (as is often the case). Add your groovy business logic for whatever events.
Compile your groovy class (ctrl+F9) then copy the .class file under WEB-INF/classes, ensuring you create the directories for the packages. There should already be a DebugListener class there which you can replace, or alternatively rename your groovy file and class name to something different.
As you’re not using a script but a proper groovy class, you can’t avoid restarting to reload your changes. My tip here is to develop against 3.13.5 which starts way faster than jira 4, providing you’re not using any jira 4-specific APIs.
On the other hand you can grab a 30-day evaluation of JRebel, which I use and wholeheartedly recommend.