Adaptavist Scriptrunner: importing groovy classes from 3rd party jar

[fischerl]

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.

[adammarkham]

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.

[fischerl]

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.

   import util.Bollo

   ^

1 error

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?

[Jimmy Anderson]

Len this believe to be issue already notified by lots of people to adaptavist it can be seen here:

https://jamieechlin.atlassian.net/browse/GRV-544

Adam he is talking about inline scripts not the external jar obviously you can refer that from script folder. 

[fischerl]

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?

[adammarkham]

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.

[fischerl]

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?

[adammarkham]

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.

[fischerl]

Thanks, Adam,

I really appreciate your help...

[Erik Nordström _stretch_se_]

@adammarkham @fischerl did you find any solution to this issue?