Relative path to jira home directory


*This issue has moved*

This issue has been moved permanently to Adaptavist's Product Support JIRA instance.

All existing users of this instance should have the same username on our Product Support instance. However, you will very likely need to click on the
Can't access your account link in order to reset to a new password.


A quick question.
I'm using the plugin for some time now, but this is a question I couldn't crack until now.
We would like to install the scripts in a subdirectory of the jira home directory, and
reference relative to that location. It simplifies upgrading.

I tried a couple of permutations of ${jira_home}/scripts/myAwesomeScript.groovy
but until now no luck ...

Furthermore, we do create groovy classes, and put them in a package such
as com.idalko.custom under the scripts directory (ie. scripts/com/idalko/custom).
We add .../scripts/ to the classpath so that the package can be accessed, but again
this doesn't survive upgrades (as we have to tweak the

Do you have any advice how to do this better ?

What's the magic - if any.





Jamie Echlin
June 14, 2011, 10:44 AM


Personally I use "../scripts/acme/com/AwesomeScript.groovy", and my directory structure is like


That way no need to change anything when I upgrade. I doubt using ${jira_home} or ${catalina_home} or something would work, unless you know different.

> We add .../scripts/ to the classpath so that the package can be accessed, but again
this doesn't survive upgrades (as we have to tweak the

I think you might be better of tweaking rather than setenv but whatever works I guess. Strictly speaking it does survive uprades, the problem is you're changing your container each time if you're using the standalone edition. If you used the war file this wouldn't be an issue.

I'd experiment a bit... one option is to compile your groovy classes and put them in a jar. In fact you should maybe not even need to compile them. The latest version of the plugin ships loads of non-compiled stuff, and has a customised resource loader to handle different jira versions requiring different scripts/classes.

It would be nice if the script runner could be provided with a resource url rather than a file name, so all the scripts could be bundled in to one jar, but it doesn't atm. But it sounds like you are trying to have your cake and eat it a bit, ie have your groovy stuff outside jira... you wouldn't be able to do this with any other plugin, and it might be dangerous anyway because different versions of jira might require different plugin versions. If you can think of a good way to handle this let me know... personally I reckon tweaking the classpath in is the easiest option.

Francis Martens (iDalko)
June 14, 2011, 10:31 PM

Is this something that the script runner could provide ?
Some configuration facility where you can specify the base directory for the scripts.
If you then include a script runner post function using a relative path, it would use
the base directory.

One step furthr is the integration with some scm
I would like to be able to incidate an svn path, with the option
to checkout a revision (or head). When JIRA starts, it can automatically do an svn up
(or something similar)


Jamie Echlin
June 16, 2011, 10:54 AM

I may try to make catalina_home and catalina_base available for use in the script paths, which would effectively allow you to set a base directory relative to one of the above.

Integration with scm... to cover all the different systems means using a maven plugin or something, which would just be bloat. You could do it yourself maybe using a component plugin implementing Startable that would checkout from hg or whatever. Thanks for your thoughts though (i did ask for them )


Jamie Echlin


Francis Martens (iDalko)



Internal Complexity


Internal Value