Monthly Archives: August 2014

Using Functions From One Groovy Script In Another

The Problem

A coworker and I spent a while on Thursday evening beating our heads against this issue.  We’d written a few functions in a separate file so that we could get them working without affecting the rest of what we’d done.  Once it was working, we went to use it elsewhere in the project, but were stuck with how to make it available to our script.

Take the following function:


def getThingList() {
  return ["thing","thin2","thing3"]

We want to use it in another script like this:


println getThingList()

The result?

$ groovy badPrintThing.groovy 
Caught: groovy.lang.MissingMethodException: No signature of 
  method: badPrintThing.getThingList() is applicable for 
  argument types: () values: []
groovy.lang.MissingMethodException: No signature of method: 
  badPrintThing.getThingList() is applicable for argument 
  types: () values: []


Obviously, the error message isn’t what we wanted out of this, so we tried the following:

import getThing.groovy
println getThingList()

More of the same. Tried to ingest the file with something I found over on stackOverflow:

evaluate(new File("getThing.groovy"))
println getThingList()

Yet again, no dice.


Reflecting on the problem that evening, I recalled that every groovy script is more or less a class with the name of the file in which the script resides ((This behavior is hinted at in the Scripts and Classes section of the Groovy documentation: “If you compile the above script to bytecode using groovyc, you get a single class named after the name of the script. e.g. if this was saved in Foo.script you’d get a Foo.class file.  You can run this Java code on the command line (assuming you’re classpath has groovy.jar and asm.jar)  This will execute the autogenerated main(String[] args) method in the bytecode which instantiates the Foo class, which extends the class and then call its run() method.”)). With that in mind, and the observation that all the files in the same folder will be part of the same package and thus available to each other without any work, I ended up with the following, which worked as I’d hoped:


thing = new getThing()
println thing.getThingList()
$ groovy printThing.groovy
[thing, thin2, thing3]

Final Thoughts

The naming of the getThing class is bad form, now that we’re actually treating it like a class.  If you’re going to write something like this, keep in mind how you’ll be using it and give the file a name more like ThingGetter.

We ended up using this arrangement several times in the project, which suggests to me that there might be a pattern to tease out of this.  We have a copy of Design Patterns around the office, so this should probably be my next stop.


Slightly More Than A Placeholder

I’ll fill this out with more content later.  The plan is to post things I find interesting and even worth sharing.  One of the first things in mind is add some notes on headscratchers I ran into with Groovy recently, as well as some talks about how we’re managing FreeRADIUS at work.