Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

Excerpt

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)

Table of Contents
maxLevel2
minLevel1

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:

Code Block
<plugin>
    <groupId>org.codehaus.gmaven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <configuration>
        <source>
            println "Hi"
        </source>
    </configuration>
</plugin>

Execute an Inline Groovy Script

Code Block
<plugin>
    <groupId>org.codehaus.gmaven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <executions>
        <execution>
            <phase>generate-resources</phase>
            <goals>
                <goal>execute</goal>
            </goals>
            <configuration>
                <source>
                    if (project.packaging != 'pom') {
                        log.info('Copying some stuff...')

                        def dir = new File(project.basedir, 'target/classes/META-INF')

                        ant.mkdir(dir: dir)
                        ant.copy(todir: dir) {
                            fileset(dir: project.basedir) {
                                include(name: 'LICENSE.txt')
                                include(name: 'NOTICE.txt')
                            }
                        }
                    }
                </source>
            </configuration>
        </execution>
    </executions>
</plugin>

Execute a Local Groovy Script

Code Block
<plugin>
    <groupId>org.codehaus.gmaven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <executions>
        <execution>
            <phase>generate-resources</phase>
            <goals>
                <goal>execute</goal>
            </goals>
            <configuration>
                <source>${pom.basedir}/src/main/script/myscript.groovy</source>
            </configuration>
        </execution>
    </executions>
</plugin>

Execute a Remote Groovy Script

Code Block
<plugin>
    <groupId>org.codehaus.gmaven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <executions>
        <execution>
            <phase>generate-resources</phase>
            <goals>
                <goal>execute</goal>
            </goals>
            <configuration>
                <source>http://mydomain.com/myscript.groovy</source>
            </configuration>
        </execution>
    </executions>
</plugin>

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.

Code Block
<plugin>
    <groupId>org.codehaus.gmaven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <executions>
        <execution>
            <phase>generate-resources</phase>
            <goals>
                <goal>execute</goal>
            </goals>
            <configuration>
                <classpath>
                    <element>
                        <groupId>commons-lang</groupId>
                        <artifactId>commons-lang</artifactId>
                    </element>
                </classpath>
                <source>
                    import org.apache.commons.lang.SystemUtils
                    if (SystemUtils.IS_OS_WINDOWS) {
                        println('Go buy a Mac!')
                    }
                </source>
            </configuration>
        </execution>
    </executions>
</plugin>

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:

Code Block
<plugin>
    <groupId>org.codehaus.gmaven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <executions>
        <execution>
            <phase>generate-resources</phase>
            <goals>
                <goal>execute</goal>
            </goals>
            <configuration>
                <scriptpath>
                    <element>${pom.basedir}/src/main/script</element>
                </scriptpath>
                <source>
                    import Helper
                    Helper.callSomeStatic()
                </source>
            </configuration>
        </execution>
    </executions>
</plugin>

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
titleWARNING

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.

Code Block
<plugin>
    <groupId>org.codehaus.gmaven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <executions>
        <execution>
            <phase>generate-resources</phase>
            <goals>
                <goal>execute</goal>
            </goals>
            <configuration>
                <properties>
                    <hello>world</hello>
                </properties>
                <source>
                    println project.properties['hello']

                    // or if you prefer, these work just the same:
                    // println project.properties.hello
                    // println project.properties.get('hello')
                    // println project.properties.getProperty('hello')
                </source>
            </configuration>
        </execution>
    </executions>
</plugin>

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.

Code Block
<plugin>
    <groupId>org.codehaus.gmaven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <executions>
        <execution>
            <phase>generate-resources</phase>
            <goals>
                <goal>execute</goal>
            </goals>
            <configuration>
                <defaults>
                    <hello>world</hello>
                </defaults>
                <source>
                    println project.properties['hello']
                </source>
            </configuration>
        </execution>
    </executions>
</plugin>

To provide a system override:

No Format
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:

No Format
fail("That ain't no woman! It's a man, man!")

Failing with an exception detail:

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

Failing with an exception detail and a message:

No Format
try {
    ....
}
catch (Exception e) {
    fail("She's the village bicycle! Everybody's had a ride.", e)
}

Resources

Goal Documentation

Groovy Development