Rupert Anderson's Blog

Mainly SoapUI, API, Open Source stuff and Elite Dangerous!

R2-Using SoapUI Groovy Grape dependencies


If you want to use a Groovy or Java library that isn’t bundled with SoapUI, then the standard way is to add it to /bin/ext and restart SoapUI, as per Recipe R1. A slick alternative approach is to use the Groovy Grape dependency manager to add Maven repository artefacts as part of your Groovy Scripts on-the-fly!

Why bother?

There’s no compelling reason to use Grape over the standard way to include dependencies. However a different approach can sometimes present its own opportunities, some differences and possible advantages are:

  • Grape dependencies can be added at runtime without a restart.
  • Grape driven scripts are self contained and document their own dependencies.
  • Grape dependencies are managed and centralised by Groovy rather than SoapUI (see the More section).
  • Ease of use – there’s no need to manually download or package Grape dependencies.


Recipe Test Version Info:
SoapUI 5.2.1 (standard distribution / installer)
O/S: Windows 10
Java: Bundled JRE

Other: ivy-2.1.0.jar,ivy-2.4.0.jar,jsoup-1.9.2.jar,jsoup-1.10.1.jar

Project Setup
To try this out, we just need somewhere to run a Groovy script within SoapUI e.g. a Groovy TestStep.


1.Create A Groovy script with unresolved dependencies
Create a script that needs a dependency that SoapUI doesn’t already have in its /lib folder. In this example, I picked a script that requires libraries from the HTML parser JSoup. The script just parses an HTML string and extracts the anchor tag and displays it in a popup (once we satisfy all its dependencies).

import org.jsoup.Jsoup
import org.jsoup.nodes.Document
import org.jsoup.nodes.Element

def html = "<p>An <a href=''><b>example</b></a> link.</p>"
Document doc = Jsoup.parse(html)
Element link ="a").first() link

2. (Optional) Test that the dependency is initially unresolved
As a test to make sure that the dependency doesn’t already exist within SoapUI’s classpath, run the above script to verify that the required imports are not resolved. You should see a SoapUI Error popup containing something like:

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: Script2.groovy: 3: unable to resolve class org.jsoup.nodes.Document @ line 3, column 1. import org.jsoup.nodes.Document ^ org.codehaus.groovy.syntax.SyntaxException: unable to resolve class….

3. Add Ivy jar
Unfortunately we can’t use Grape without first adding the Ivy jar. At time of writing the latest version of ivy is ivy-2.4.0.jar, this can be obtained from:

For classpath reasons this needs to be added to /lib (not /bin/ext/) otherwise you will see the error:

SoapUI missing Ivy dependency

3. Add a Grape statement

To get the script working, we need to use Grapes to include the JSoup dependency. Again, Maven Central can help us, as it provides a useful Grapes tab with the syntax we need:

@Grab(group='org.jsoup', module='jsoup', version='1.10.1')

Then paste this in above the imports like so:

@Grab(group='org.jsoup', module='jsoup', version='1.10.1')
import org.jsoup.Jsoup
import org.jsoup.nodes.Document
import org.jsoup.nodes.Element

def html = "<p>An <a href=''><b>example</b></a> link.</p>"
Document doc = Jsoup.parse(html)
Element link ="a").first() link

4.Run the script successfully!
Run again, and you should see the anchor tag from within the html variable extracted and output in the log:

<a href=""><b>example</b></a>


Local Repository

If you were wondering where SoapUI stores the locally cached artefacts when they are downloaded, the default location is:


If you have Groovy installed, then typing the following in a shell:

grape list

Will give you a list of all artefacts cached in the above location.

For configuration options please see:

Feature Request

If you like using the Grape functionality and would like to see Grape dependency management added as part of the standard SoapUI product, then maybe vote for this feature request:


  • For more JSoup examples see

2 Responses to R2-Using SoapUI Groovy Grape dependencies

  1. Rao says:

    Hi Rupert,

    This is nice article. Will try once I get chance.
    Hope many people out there in the community would benefit out of it.

  2. Rup says:

    Hi Rao,

    Thanks, I value any feedback you can give me on it.

    If you get a chance to try it out, please can you double check whether adding the ivy jar to /bin/ext/ also works? I found that it didn’t during my tests (which kindof made sense, because that /ext lib classloader is secondary to the SoapUI /lib classpath where Groovy exists), but I have seen others suggest that it does work. It wouldn’t be a big deal, but I want to be as accurate as I can! 🙂


Leave a Reply