This plugin moved to http://confluence.atlassian.com/display/JIRAEXT/Groovy+Runner. There is some background info here though.
I discovered the JIRA Groovy Runner recently, whilst looking for a starting point to integrate Jython in to JIRA. I succeeded in adding a Python runner, but then realised it wasn’t particularly useful, me not being a strong Python programmer.
However, it did make me look harder at the Groovy Runner, and manage to extend it somewhat to cover Conditions, Post-Functions, Validators and services… In theory you can cover all the areas where JIRA provides something to hook in to, eg Portlets, Reports, Listeners, Services etc.
The main advantage for me in using Groovy here, is that using a Groovy script (as opposed to a Groovy class), you can quickly test and debug your post-function (or whatever), and make changes without having to restart JIRA. Another big advantage, is that Jetbrains IDEA has full support for Groovy (debugging, intellisense, interefactoring) etc. And finally the language itself tends to make you more productive when doing RAD-type work. Having completed the Groovy script to your satisfaction, you can either write it properly as a java plugin, or just leave as is.
Take an example… I was using a Condition that checks all sub-tasks are in a certain state. I then added another state to the sub-task workflow. Rather than adding the additional state as a parameter, I just wanted it to allow the transition if all sub-tasks had a resolution, regardless of their status.
Using a
loading http://blogs.onresolve.com/jechlin/55/SimpleAllResolved…
The fact that you can debug this, make changes, and rerun it without restarting JIRA is a huge advantage…

It will also be useful where you have complex business logic for something like a validator, that you don’t have time to parameterise properly… e.g. Date A must me after Date B, unless Option C is checked.
If you write Groovy from a java perspective you can pretty much paste it in to your java file. A lot of the time spent when writing a plugin is all the plumbing, e.g. the factory class, the templates, and messing around with atlassian-plugin.xml. This lets you avoid some of that whilst you scope out your plugin.
Usage
- Download Groovy-runner.jar or source. Copy jar in to WEB-INF/lib.
- Download Groovy. Copy Groovy-all-n.n.n.jar to WEB-INF/lib.
- Turn up debugging:
loading http://blogs.onresolve.com/jechlin/55/log4j.properties…
- Restart JIRA.
- Add a new condition, post-function, validator or service. Give the path to the Groovy script relative to the working directory of your JIRA instance, which is $CATALINA_BASE in the standalone version.
- Note that the template implies you can paste in Groovy text - I removed that capability because I didn’t think it was useful.
- It may be handy to create a directory called groovy_scripts at the root of your installation, to store the scripts.
- Start small:
loading http://blogs.onresolve.com/jechlin/55/StartSmall.groovy…
- In the file path, enter the name of the script, eg groovy_scripts/myvalidator.Groovy.
Debugging
You can put breakpoints in your Groovy script, your IDE should stop execution when they are hit.
I’ve had good success with Intellij IDEA, but Eclipse has a Groovy plugin as well.
Examples
None of these have had much, if any, testing.
Validators
One field or the other is required, not both. Jira Suite Utilities can require that a field is present, but not more complex stuff like one field or another is required, but not both, and not neither. Horribly contrived example to require a Sponsor OR a description.
loading http://blogs.onresolve.com/jechlin/55/OneOrOther.groovy…
To disallow the transition you set invalidInputException to an instance of a new InvalidInputException. This is a hack, but I couldn’t work out how to throw an InvalidInputException in a script and have it caught by the class invoking the script.
NB - this has a dependency on Jira Suite Utilities for simplicity of code.
Conditions
All sub-tasks must be resolved:
loading http://blogs.onresolve.com/jechlin/55/AllSubTasksResolved.groovy…
Current user is equal to the value of a field, eg Sponsor:
loading http://blogs.onresolve.com/jechlin/55/OnlySponsor.groovy…
Sub-tasks all assigned to me
loading http://blogs.onresolve.com/jechlin/55/SubTasksAssignedToMe.groovy…
“Depends on” links all need to be resolved:
loading http://blogs.onresolve.com/jechlin/55/LinksBlocking.groovy…
Only allow changes in the afternoon (!):
loading http://blogs.onresolve.com/jechlin/55/ChangesInMorningOnly.groovy…
The problem I have with conditions, is that when a condition is failed, the transition is not displayed. This can lead to confusion for users - “I’m sure I saw that action the last issue I looked at, and I think I’m supposed to resolve this, but the link isn’t there”… followed by a support call. Ideally if a condition is failed the link should be present but disabled… when you mouse over it it could you give you some explanatory text, eg “Cannot resolve because this issue depends on issues that are not resolved”. You could provide that message as a parameter in the condition.
The other odd thing is that conditions seem to be invoked three times for every page view, not once as I would expect.
If not obvious from the examples, set passesCondition to true/false depending on whether you want the condition to be allowed or not.
Post-functions
Auto close all child issues.
loading http://blogs.onresolve.com/jechlin/55/AutoCloseChildIssues.groovy…
Automatically append some generated comment on a transition:
loading http://blogs.onresolve.com/jechlin/55/AddComment.groovy…
Use a regular expression to copy a string from one field, to another (NB this relies on the JIRA Suite Utilities jar):
loading http://blogs.onresolve.com/jechlin/55/CopyRegEx.groovy…
Create another issue, possibly in another project, that is dependent on this one:
loading http://blogs.onresolve.com/jechlin/55/CreateDependentIssue.groovy…
Services
A Groovy service is included. I have not included an output file location - you can configure log4j to have it log to a separate file if you like.
Performance
Note that all these are Groovy scripts as opposed to a Groovy class, and as such, that there is a performance penalty to pay when the script is “compiled” and run. As far as I know you could use a Groovy class anywhere you can use a java class in JIRA, and it’s compiled to bytecode there will be little performance impact.
Mostly I am not fussed about performance, the penalty to pay on something like a post-function which runs relatively infrequently is not anything to get worried about. However, that is different for conditions, especially if you have large list of sub-tasks, or you use the plugin that shows available workflow actions on the issue navigator.
I did experiment with using Groovy classes, but could not get them to reload without restarting JIRA (which is my main goal here). I had an experiment using JCI but couldn’t get it to work.
Problems
The exception handling is not very good.
Also there is no way to pass parameters to your function. Because they’re easy to modify, I would just copy the script and hard-code params in there. Going forward it would be nice to have a text area, where you can pass arguments to the script in java properties format.
24 Responses to “JIRA-Groovy Plugin”
Leave a Reply
You must login to post a comment.
NB - I need to recompile this targeting earlier JVMs. Currently you can only run it with java 6.
Hi Jamie,
how can I build the source from the source jar you have linked to? I need a Java 5 compatible version.
Thanks!
Hi Frank - I’ll post a java 5 compatible version asap, hopefully Friday (18th Apr), more likely monday. To compile your own, well, if you’re used to doing it it would be easy enough, if not then probably it’s not worth the trouble, and I will get back to you shortly.
cheers, jamie
Hi Jamie.
Can you please post the required dependencies, e.g. as an Ant build script, pom.xml, Eclipse settings etc? It’s just hellish to define them manually.
Merci, Frank
Hi Frank,
Sorry, I am not really set up to use the jira build system which is new with 3.12. I’ve recompiled them for 1.5 so you should just be able to drop the jars in now. The only requirement is for the groovy interpreter/compiler, as mentioned in the installation step.
cheers, jamie
I concur with your statement above about workflow conditions hiding transitions from the user - do you have a solution for this, i.e. making a transition which is blocked by a condition show up as “grayed out” with a tip indicating why?
Have you submitted this plugin to Atlassian? The groovy plugin there is very much out of date, plus… I’ve been considering a plugin exactly like this.
I’m going to give this a shot.
Is there any way to change the issue type of an issue?
We’ve got an issue type of “WIBNI” - which is “Wouldn’t It Be Nice If…”
When an issue is rejected as Expected Operation, I’d like to provide the user with an option to “Resubmit as WIBNI” which would simply change the issue type from Bug to WIBNI.
There doesn’t seem to be an easy way of doing this, as I don’t want basic users to be able to move issues (which seems to be the defacto method)
Cheers.
Scott
I’d take a look at com.atlassian.jira.web.action.issue.MoveIssueConfirm. Most of that code won’t be required if both issue types have the same workflow and same custom fields - if that’s the case, should be pretty trivial. If not, then, it’s harder.
jamie
Jamie
I am running 3.13.3.. but when I drop in this plugin (along with groovy-all-1.6 and groovy-1.6 jars, the plugin is not picked up or recognized by Jira at all.
What do you think I should be doing to get this working on 3.13.3 ?
- Ram
Ram,
I haven’t tested it with 1.6 at all - the latest version I have tested it with is 1.5.7. However, if it didn’t work I’d expect there to be errors in the log file.
Did you look at that?
cheers, jamie
Jamie -
You mention a Groovy Service. I can’t find it - probably just not looking in the right place - and would like to use it, so that I can replace some nasty Jelly scripts with something a bit nice.
Thanks!
Jordan
Jamie -
How about custom fields? Have you done anything there?
Jordan
Hi Jordan,
I did think about doing something with custom fields, but that was superceded by some other plugin I’ve got going on the very back burner.
> You mention a Groovy Service. I can’t find it
Possibly a file is missing. Anyway I’m moving this to confluence and giving it a bit of a revamp with some more instructions.
Try this:
Add a new service with class: com.onresolve.jira.groovy.GroovyService. Call it anything. Then enter the script file relative or absolute path. As usual, start with a simple “Hello World” service:
import org.apache.log4j.Categorylog = Category.getInstance("com.onresolve.jira.groovy.example.testService")
log.debug("Service testService script running")
cheers, jamie
HI Jamie -
Thank you! The assistance here and on the Groovy Plugin page were a big help.
I am going to be translating some nasty, but important, Jelly Scripts to Groovy in the near future.
Would love to discuss with you what it would take to get things so that we could write custom fields in Groovy (hey, and how about full on plug-ins :-)).
Thanks!
Jordan
Hi Jordan,
I’m interested in doing things with custom fields, my next plugin allows a lot of manipulation of custom field stuff with groovy, although it’s very much in the alpha stage at the moment.
Regarding full-on plugins, that shouldn’t be a problem, both the workflow diagram plugin and copy project plugin are groovy only:
http://confluence.atlassian.com/display/JIRAEXT/Visualising+JIRA+Workflows
http://confluence.atlassian.com/display/JIRAEXT/Copy+Project+Plugin
cheers, jamie
Hi,
I’am developping jira plugin, i search a solution to developp jira plugin without every time run maven commands “mvn -Pplugin-debug”, and put the jar after under “Web-Inf/lib” , i’aw working with eclipse IDE, i’am trying to find a solution with jira groovy plugin.
thank you for your help
That’s the point of using a groovy script, you don’t need to do any of the above. You just modify your script and then retry the action or whatever.
jamie
Jamie,
Any change of posting something about getting Jython running inside JIRA?
~Matt
Hi Matt,
I was thinking of modifying the groovy runner to allow any language that complies with JSR-223. However I got bogged down with scriptable custom fields so hasn’t been much progress.
chers, jamie
Hi Jamie,
Excellent plugin, any plans to implement listeners?
Cheers
Dave
Dave, see http://blogs.onresolve.com/?p=122.
Sorry might not be the right post but I see some posts like
(Script Runner JIRA Plugin)http://blogs.onresolve.com/wp-admin/post.php?action=edit&post=122
Highlight Overdue Issues(http://blogs.onresolve.com/wp-admin/post.php?action=edit&post=111)
I cannot view them any idea why? It says “You are not allowed to edit this post”, i want to just view it
Thanks
Dave,
Not sure why you see those links. To view the posts they are at http://blogs.onresolve.com/?p=122 and http://blogs.onresolve.com/?p=111 respectively.
cheers, jamie