SOURCE DIRECTORIES For the Groovy-Eclipse plugin, put Java and Groovy sources in the src/main/java and src/test/java directories by default.

I put my Groovy files in src/main/java and src/test/java. Now I can build the project using

mvn clean install

I can even execute the project using the exec:java (!) task, both using the default WOEID and with a supplied command-line argument:

> mvn exec:java -Dexec.mainClass=mjg.RunDemo

...

Weather for Boston, MA, United States: Condition : Cloudy

Temperature: 58

Wind Chill : 58

Humidity : 84

I can supply a command-line argument using –Dexec.args:

> mvn exec:java -Dexec.mainClass=mjg.RunDemo -Dexec.args='44418'

...

Weather for London, , United Kingdom: Condition : Cloudy

Temperature: 54

Wind Chill : 54

Humidity : 82

A guiding principle in this book is that Java is good at tools, libraries, and (existing) infrastructure, and that Groovy is good at everything else. It’s hard to imagine a better demonstration of that than the current example. The entire application was written in Groovy, at a code savings on the order of 10 to 1. The infrastructure treated the code as though it was all Java, and I was even able to use the Java exec task to execute the Groovy script to drive the application.

The Groovy-Eclipse compiler plugin is a funded project, because it’s used inside the IDEs provided by SpringSource (a division of VMware).8 The quality of the plugin, especially for cross-compilation, is therefore quite high. Just because it has the name “Eclipse” wired into it, there’s no reason not to use it in a Maven project. There’s no implication that the plugin is exclusive to the IDE. You can use it anywhere, as I did with the Maven project in this section.

The other way to add Groovy to a project built with Maven is to use the GMaven project, discussed in the next section.

5.4.2The GMaven project

GMaven is an alternative approach for adding Groovy into Maven projects. It works with combined Java and Groovy sources by generating stubs for the Groovy files as part of the build sequence.

8 Now part of Pivotal, which is owned by VMware, which is owned by EMC…

www.it-ebooks.info

To help users get started, the project provides a Maven archetype called gmaven- archetype-basic. To use the archetype, execute the following at the command line:

> mvn archetype:generate –DgroupId=mjg –DartifactId=weather –DarchetypeArtifactId=gmaven-archetype-basic -Dversion=1.0-SNAPSHOT –Dpackage=mjg

This again produces a project in standard Maven structure, in which the sources are in src/main/groovy and the tests are in src/test/groovy. The plugin expects both Java and Groovy sources to reside in those directories.

The generated POM is shown in the following listing, with some modifications discussed in the listing.

www.it-ebooks.info

<goal>testCompile</goal>

</goals>

</execution>

</executions>

</plugin>

</plugins>

</build>

</project>

The POM needs a Groovy dependency. It doesn’t have to be global, but it was just as easy to add it that way here. The provider was adjusted to 2.1.5 in order to use Groovy version 2.

Building the system is done with a standard Maven install:

> mvn clean install

During the build process, Java stubs are generated for each Groovy file. The stubs themselves are quite minimal; they’re only used to resolve the inter-language dependencies rather than execution. As an example, here’s a portion of the stub generated for the Weather class, whose Groovy implementation was shown in the previous section.

Listing 5.12 Part of the Java stub generated from Weather.groovy

public class Weather extends java.lang.Object

implements groovy.lang.GroovyObject { public groovy.lang.MetaClass getMetaClass() {

return (groovy.lang.MetaClass)null;}

public void setMetaClass(groovy.lang.MetaClass mc) { } public java.lang.Object invokeMethod(

java.lang.String method, java.lang.Object arguments) { return null;} public java.lang.Object getProperty(java.lang.String property) {

return null;}

public void setProperty(

java.lang.String property, java.lang.Object value) { }

public java.lang.String getCity() { return (java.lang.String)null;} public void setCity(java.lang.String value) { }

// ... remaining getter and setter methods

}

Any Java class can be treated as though it was Groovy source by implementing the GroovyObject interface, as the stub does here. The first five methods in the stub provide no-op implementations for all the methods in that interface. The rest of the stub consists of empty implementations for the remaining methods, which in this case are the getters and setters and the toString method.

The stub generated for the RunDemo class is slightly different, in an interesting way. The Groovy implementation is just a couple lines of scripting code. As noted in the demonstration in chapter 3 where I executed a compiled Groovy script from the java command, every Groovy script is ultimately converted to a class by the compiler, and the corresponding RunDemo.java stub illustrates this:

www.it-ebooks.info

public class RunDemo extends groovy.lang.Script { public RunDemo() {}

public RunDemo(groovy.lang.Binding context) {}

public static void main(java.lang.String... args) { } public java.lang.Object run() { return null;}

}

The class extends groovy.lang.Script, has a default constructor and a constructor that takes a groovy.lang.Binding, a standard Java main method, and a run method. All Groovy scripts look like this to the JVM. Running the script is like executing the main method, which delegates to the run operation here.

As before, to run the program using the Maven you call the exec:java task with the right arguments. In this case that means the main class is either RunDemo or

RunInJava:

>mvn exec:java -Dexec.mainClass=mjg.RunDemo

>mvn exec:java -Dexec.mainClass=mjg.RunInJava

Either way, the result is the same as in the previous section.

The GMaven project has been quiet recently, but it’s still alive. As demonstrated, the archetype works and the stub generation allows the plugin to delegate compilation to the standard Maven tools.

Lessons learned (Maven)

1There are two separate ways to add Groovy to Maven builds, each with benefits and drawbacks: the “Groovy Eclipse” plugin and GMaven.

2If at all possible, consider moving to Gradle.

5.4.3Maven summary

There are two ways to add Groovy dependencies to a Maven project: the GroovyEclipse plugin and the GMaven project. My advice (which may change as the projects evolve) is

1For an already existing Maven build, add the Groovy-Eclipse plugin. It works, and a company that has a significant interest in the success of Groovy financially supports development of the plugin itself. The fact that the name includes the word Eclipse is irrelevant.

2For new projects either plugin will work, but the existence of a Maven archetype makes it particularly easy to get started with GMaven.

3It’s quite interesting that both plugins expect Java and Groovy sources to reside together. There’s a significant integration lesson there somewhere.

Moving now from hybrid approaches to purely Groovy solutions, I’ll address first the short and sweet Grapes approach before moving to the real destination: Gradle.

www.it-ebooks.info