Follow Us on Twitter

Devoxx 2011 – The Groovy Ecosystem

by Roger Goossens on December 14, 2011 · 0 comments

My last talk at Devoxx was the one that perhaps i enjoyed the most and one that I was really impressed by. A lot of neat products based on Groovy were discussed in this talk. They had a lot in common. Besides all being based on Groovy, they also have a very simple installation procedure in common: just download the product, unzip it, and add the executable to the PATH variable. And voilá, you have a command line tool at your disposal linked to the product you downloaded.

The talk was presented by Andres Almiray. All the products he discussed, he demoed by using a text editor and a command line (and sometimes a web browser), which was pretty cool. It furthermore emphasized the simplicity of working with the different products. Like Andres did in his presentation, I will focus this blog on Grails, Griffon and Gradle and only give a short summary of the other products.


First up was maybe the most widely known product in the Groovy eco-system. Grails is a high-productivity web application framework based on Spring, Hibernate and Sitemesh. It’s a widely used framework and currently there are over 600 plugins available for Grails, facilitating the addition of custom functionality (like file uploading or integration with soap or rest services) to your web application.

With Grails you bring Rapid Application Web Development to the table. In no time Andres got a CRUD application up an running.

First he created a basic Grails application

$ grails create-app devoxx

Next, he added some domain classes

$ grails create-domain-class Author
$ grails create-domain-class Book

This created the Author.groovy and Book.groovy class files.

The relation between the two classes Andres added manually by adding the following line of code to the Author class:

static hasMany [books:Book]

With the domain classes in order, we can now create 2 controller classes AuthorController and BookController:

$ grails create-controller Author
$ grails create-controller Book

Now, to enable auto-generation of the view layer of the application based on the domain classes, we have to enable a feature called scaffolding. The following line of code added to the AuthorController takes care of this:

static scaffold = true

Now all is in place for running the application:

$ grails run-app

With scaffolding in place all the views for the CRUD app get auto-generated (as .gsp pages). The run-app command furthermore packages the application and bootstraps TomCat. Now you can reach the application at the following url: http://localhost:8080/devoxx/author.

One additional benefit of using these basic commands to rapidly generate a prototype is that every generated class gets to appear in its own default package, given that Grails is based on the configuration by exception paradigm. Scaffolding is based on templates and all these templates can be customized to fit your needs.

After the basics Andres shows some additional Grails features. All of them very easy to add to the application:

  • Adding constraints to domain classes (Grails error messages support i18n);
  • Creating a taglib: $ grails create-taglib;
  • Launching the Grails console, an interactive playground, similar to the Groovy console: $ grails console
  • The grails war command: $ grails war;
  • Installing the Grails REST plugin: $ grails install-plugin rest;
  • Creating and packaging a custom plugin: $ grails create-plugin / $ grails package-plugin.


Griffon is similar to Grails. It’s a high productivity framework for building Desktop applications. Griffon is a relatively new framework. It already has nearly 200 plugins available though.

A lot of the commands in Griffon are similar to the commands used in Grails. Here are some useful commands:

$ griffon create-app devoxx
$ griffon run-app
$ griffon run-applet
$ griffon run-webstart

Views are by convention filed under the view directory in a Griffon project and are named …View.groovy. Griffon uses bindings to couple fields or properties in the view layer to bean properties in the model layer. Here are some code snippets to illustrate:


@Bindable String input
@Bindable String output


def copy = {
  // model gets injected by Griffon
  model.output = model.input



The controller copy method copies the input property of the model to the output property. Both properties are bound in the view to text fields.

One of the key concerns that’s difficult to manage in Swing applications is threading. And this is something in which Griffon really shines. For example if you have a controller method you want to execute in a thread separate from the UI Thread, you add the following annotation:


As an alternative you can make use of the following Griffon methods to execute pieces of code in the threaded manner you want:

  • execAsync: execute the code in the UI Thread asynchronously;
  • execSync: execute the code in the UI Thread synchronously;
  • execOutside: execute the code outside the UI Thread.

Griffon also supports an event mechanism. You can launch an event called Devoxx and include a list of parameters with the following Griffon code:


Like the exec method, there’s also a variant for asynchronous events (app.eentAsync) and one for outside events (app.eventOutside).

A possible event handler could look like this:

def onDevoxx = { n1,n2,n3 ->
println: "Devoxx $n1,$n2,$n3"

A lot of the create- commands from Griffon also let you generate artifacts in Java instead of Groovy. Simply add fileType=java to the command. One interesting, though not very surprising, fact to note is that the Java files are a lot bigger compared to the same files generated in Groovy.


Gaelyk is a lightweight Groovy toolkit for Google App Engine Java. Google App Engine is a so called Platform As A Service and provides a Java 6 Runtime Environment.


Gradle is a Groovy alternative to Maven. It’s a tool for building applications. It uses Groovy DSL (Domain Specific Language) instead of XML and adheres to specific Maven conventions.

This is an example of a simple Gradle build file for a java project (compare that to a simple Maven file):


apply plugin: 'java'

This is a build file for a java project that uses the same default conventions as Maven does (like java source files are by default placed in the src/main/java directory).
To build a project based on this build file, simply type:

$ gradle build

When you issue this command, Gradle bootstraps and builds the project. When you issue the command a next time and there are no changes, Gradle is able to recognize this and doesn’t perform an unnecessary second build. You still lose the amount of time needed for bootstrapping Gradle. There’s also an experimental daemon available, so you can go without even the bootstrapping time. Gradle, like Maven, uses configuration by exception. So, like Maven, you can do without the default structure of a project is that doesn’t fit your needs. But you have to add additional configuration code to your build file.

Dependency management in Gradle by default uses Maven repositories. For example, to add a compile dependency for commons-lang, your build file would need these additional lines of code:

repositories {

dependencies {
    compile 'commons-lang:commons-lang:2.6'

To view a list of dependencies for the current project you can issue the following Gradle command:

$ gradle dependencies

Multiprojects in Gradle are very easy. Assume you have a multi project with two projects multi-core and multi-ext, where multi-ext is dependent on multi-core. You first add a settings.gradle file next to the build.gradle file for the root project:

include 'multi-core'
include 'multi-ext'

Next you add a dependency on multi-core in the build.gradle file of the multi-ext project. And that’s all there is to it. When you now build the multi-ext project, the multi-core project also gets build. Changes to the multi-core project are also picked up when rebuilding the multi-ext project.

To build a pom file for your current project, issue the following command:

$ gradle install

Like Maven, you can define properties in Gradle in a file.

The open source projects Grails and Griffon both use Gradle as their build tool.


Gant is a Groovy version of Ant. You have the power of Ant at your disposal but in a Groovy way, thus without the bloated xml.


easyb is a behavior driven development (BDD) framework. Stories and specifications are written in Groovy. It is comparable to JBehave, which does the same in Java.


Spock is a testing and specification framework for Java and Groovy applications.


CodeNarc is an equivalent to the java tools findBugs and checkstyle. It’s a tool for analyzing Groovy code and detecting bugs, coding malpractices and the like. There are plugins available for Grails, Griffon and Gradle.


Gpars lastly is a framework aimed to simplify concurrency programming in Java or Groovy.


Devoxx 2011 - The Groovy Ecosystem, 4.7 out of 5 based on 3 ratings
VN:F [1.9.22_1171]
Rating: 4.7/5 (3 votes cast)

{ 0 comments… add one now }

Leave a Comment


Previous post:

Next post:

About Whitehorses
Company profile

Whitehorses website

Home page

Follow us
Blog post RSS
Comment RSS