We have a 3rd party jar which contains some classes I would like to use in my inline scripts in Scriptrunner. We have tried putting the jar in the .../WEB-INF/lib, which didn't work (unresolved import). We tried putting the class (.class file) in the WEB-INF/classes directory, same problem.
We tried putting the .groovy file in the scripts root directory, which could not be imported into the inline scripts either.
We are using JIRA 7.0.5 and Scriptrunner 4.3.5. Does anyone have any solutions for us?
Edit: We did restart JIRA after adding the class and the jar
EDIT AGAIN: Ok, we are getting somewhere I think, the problem was the .class files were groovy classes, not java classes, and there is no groovy runtime support on the classpath. Adding a groovy runtime jar in the WEB-INF/lib directory looks like it fixes the problem, although that certainly does not feel like the 'proper' solution. It is, after all, being called by a groovy script.
External third party JAR dependencies should be placed under /WEB-INF/lib then restart JIRA.
Importing Groovy classes from *.groovy scripts, is possible by placing them in the script root under the appropriate directories which match the package declaration. Please see here for an example of this: https://scriptrunner.adaptavist.com/latest/jira/#_script_roots
You should not need to add a separate groovy JAR and it will likely conflict with what ScriptRunner uses.
Let me know if you need any further clarification on what your trying to do.
Thanks for your response, Adam!
I have seen the example you have cited, and we get that to work. The problem we have is that we can not get the "Inline scripts" importing properly from the *.groovy scripts that are under the script root. If the script is written as a "Script file" we have no problem, just as in the example you cited.
Some listeners do not allow us to specify a "Script file", such as the "Fast-track transition an issue" under "Script listeners" has a "Condition" and "Additional issue actions". So we do not have the option of using a "Script file" for these cases.
When we put in an import statement (such as: import util.Bollo) into the "Condition" of a "Fast-track transition an issue" the static type checking of the web page accepts it without complaint. But when the listener is run we get a problem, the log for the run shows this error:
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script5.groovy: 1: unable to resolve class util.Bollo
@ line 1, column 1.
So, is it possible to import *.groovy classes that are under the script root into inline scripts?
Also, is it possible to add compiled groovy classes (*.class) into the web-inf/classes or jars containing groovy *.class files into web-inf/lib without adding any groovy jars?
Thanks Jimmy, so I guess I am out of luck trying to share code that is under script roots into inline scripts. By the way, for the sake of others reading, issue in the link Jimmy helpfully provided has been moved to: https://productsupport.adaptavist.com/browse/SRJIRA-458
So, now it looks like our only alternative to share code with inline scripts is to put compiled classes (*.class) into the web-inf/classes or jars into web-inf/lib. (And, of course, restart Jira). We have got this working with java classes.
However, when we try it with compiled groovy classes, it does not work. We get "can not resolve imports". When we tried to call a java class which called a groovy class we got a long stack trace which indicated that there was not basic groovy support available on the classpath. When we added groovy-2.4.7.jar to web-inf/lib (and restarted Jira) everything worked fine. I am sure adding the groovy jar to the web-inf/lib is not a good solution, as Adam pointed out.
We want to use groovy for our shared code base, not java.
So, now my only remaining question is, is there a way to add compiled groovy classes to web-inf/lib or web-inf/classes and import from inline scripts without adding a groovy-2.4.7.jar to the web-inf/lib?
Hi Len, Unfortunately this is a known issue for ScriptRunner due to the way the classes are loaded for the different scripts. We will look at fixing this in the future.
You should package your Groovy classes up into a JAR file and then add that to web-inf/lib then restart JIRA, that should work.
Hi Adam, thanks, I understand we have to put our shared code in the web-inf/lib.
But, regarding the Groovy classes in a JAR in the web-inf/lib:
We have tried putting Groovy classes (*.class) and Java classes into a jars, and adding the jar to web-inf/lib and restarting JIRA. We can resolve the imports for the Java classes from inline scripts no problem, but cannot resolve the imports for the Groovy classes.
Also, if we try calling a Java class that then calls a Groovy class, we get into the Java code, but when it gets to calling the Groovy class, it fails and we get a long stack trace that indicates there is no run-time Groovy support.
When we add groovy-2.4.7.jar to the web-inf/lib directory, we then can resolve the imports and call the Groovy classes. Everything works, but only when we add the Groovy support jar (groovy-2.4.7) to the web-inf/lib. To me, this indicates that there is no Groovy support available on the run-time classpath when called from inline scripts.
So, basically, for calling code installed in web-inf/lib from inline scripts, calling Java works, calling Groovy doesn't.
Is this a known issue? Or are we missing something simple?
Yes thats correct, sorry if I misunderstood your question. We don't support that. Adding the Groovy jar may mean you run into class loading issues.
Ideally we will look at fixing this going forward.
Jira may be a staple part of your workday, but your colleagues, customers, business partners or an auditor might need information presented in a different format, that is easy to access and read. And...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events