Skip to end of metadata
Go to start of metadata
Executing Groovy code from Maven is a snap with GMaven.

Groovy source can be configured inline from POM configuration, or from an external file or URL source, have additional property configuration, better defaults and well just makes you feel happy (smile)

Default Variables

By default a few variables are bound into the scripts environment:

project

The maven project, with auto-resolving properties

pom

Alias for project

session

The executing MavenSession

settings

The executing Settings

log

A SLF4J Logger instance

ant

An AntBuilder instance for easy access to Ant tasks

fail()

A helper to throw MojoExecutionException

Examples

These examples all using Maven executions which means that it binds the execute goal to a build phase. The configuration of source inside of an execution is only available for that execution. If you want to be able to mvn groovy:execute from the command-line, then you need something like:

Execute an Inline Groovy Script

Execute a Local Groovy Script

Execute a Remote Groovy Script

Class Dependencies

Using Java Classes

Scripts can use Java classes. To include custom classes to be available to the script define a classpath which contains additional artifacts to included in the scripts classloader.

This is the preferred mechanism to extend a scripts classpath instead of adding dependencies to the plugin, which may cause problems if the classpath needs to be different on more than one plugin execution or when it differs between usage in more than one module in a multi-module build.

Artifact definitions will pick up missing details from the POM's dependencyManagement section.

Using Groovy Classes

By setting the scriptpath you can load additional Groovy classes.

For example if you have a class named Helper defined in a file named ${pom.basedir}/src/main/script/Helper.groovy your scripts can use that class:

Custom Properties

By setting the properties parameter additional project properties can be added for an execution.

Properties will automatically resolve when accessed. This means that if you have defined a property with a value of ${session}  that when you access it from your script, the returned value will be the MavenSession instance, just as one would expect when using @parameter expression="${session}" in a Mojo annotation. Though as noted below, default values are handled slightly differently than what is done currently for Mojo annotations.

WARNING

Icon

Property expressions are not GStrings, they are Maven expressions.
You need to use the ${foo} syntax for them, $foo will not work.

Because of this property resolution, the value of a property might not be a String as one might expect when talking about normal Java properties. But, just for us Groovy doesn't really care what the type is.

By setting defaults additional project properties can be added for an execution which will be used only if the project or system does not override.

To provide a system override:

mvn -Dhello=jason

Script Helpers

Using fail()

Sometimes executed Groovy scripts need to fail the build. To do so with out causing evil stack traces or assert experssions to get spat out, you need to throw a MojoExecutionException. To help make this a little bit easier there is a fail() closure bound the the default namespace for the executed script.

Failing with a simple string:

fail("Some meaningful message about the fatal error.")

Failing with an exception detail:

try {
    ....
}
catch (Exception e) {
    fail(e)
}

Failing with an exception detail and a message:

try {
    ....
}
catch (Exception e) {
    fail("Some meaningful message about the fatal error.", e)
}

Resources

Goal Documentation

Groovy Development

  • No labels

7 Comments

  1. How can arguments be sent to a script file?

    I have tried the following with no results at all (param1 and param2 having value):

  2. Currently, you'd have to use custom properties as described on this page rather than command-line arguments.  If you'd like, you can open a Jira for this and I can look at how hard this would be to implement.

  3. I use mvn groovy:shell to rapidly prototype. I have a base test class (extending GroovyTestCase) which I'd like to work with, but saying myInstance = new my.test.package.MyBaseTestClass() doesn't work: "unable to resolve class"

    I had hoped it would be on the classpath by default. Is there a way I can make this classes available on the classpath in the groovy shell when started with mvn groovy:shell?

  4. Is it possible to modify existing properties or add new properties that can be used in other parts of the pom?

    If so, how?

    I tried a simple assignment a la:

    project.properties['test'] = 10

    and then use it in another part of the pom.xml as the property: ${test} or ${project.properties.test} but they are not (yet?) defined there.

  5. I find the sample code in the fail() documentation incredibly crude. Does anyone find the try/catch example funny or appropriate?

  6. Sorry, for not replying earlier.  Since basically forking the project, I've not really done anything more with GMaven.  I totally never noticed that before.  Personally, I'm inclined to agree with you.  I've gone ahead and changed the message.