Interview with Grails Project Lead Graeme Rocher about Status and the Future of Grails


Just in time for Christmas 2009, the new Grails version 1.2 was released. In this context, JavaMagazin author and Grails expert Marc-Oliver Scheele interviewed the head of Grails; Graeme Rocher. Graeme is the co-founder, project manager and lead developer of the Grails framework.

In 2006, Graeme published the first version
of Grails. At that time he was employed as CTO of the
company, Skills Matters. Next, he founded a
consulting and development company for Groovy and Grails with
other groovy experts; G2One
. In 2008 this company was
acquired by SpringSource, which in turn was acquired by VMWare in

Graeme continuous his work as Head of Grails
Development at SpringSource, which remains an
independent division of VMWare. Furthermore,
he is the author of the standard work
The Definitive Guide to Grails and a
regular speaker at conferences.

Graeme, let us go back in time. Please tell us
briefly what
 was your motivation
Grails framework? Did
 you have to
implement a specific project or was it a kind of personal, fun
project in the early days?

I was CTO at a company that developed custom Learning
Management (LMS) and Content Management (CMS) systems. The systems
were sold as bespoke tailored solutions with the cost of the
customization of the LMS/CMS included in the sale. With this kind
of fixed price work we needed to be ultra-productive, otherwise the
cost of the customization would start eating into

The basis of the LMS and CMS system was built with Spring
and Hibernate, and although I liked what I saw of projects like
Ruby on Rails and Django, they were unusable in the majority our
clients environments. However, I had already had exposure to using
Groovy on another project (a build system for producing eLearning
content from MS Word documents) so I decided to see if we could
achieve similar levels of productivity.

As it turned out, there were movements on the Groovy
mailing list to create a Rails-like framework, so I decided to help
kick start the project. What emerged was Grails and I have former
clients who are still running Grails 0.1 based CMS systems in
production. Over time Grails got very popular and so we decided to
form a company (G2One, later acquired by SpringSource).

Now four years have passed and Grails is a widely
and very successful
framework. The
unique selling
compared with
other Java-based
sis the
very small development effort for implementing sophisticated
web applications.
Can you share some
impressive in terms of
development speed and complexity?

Sure. There are many projects out there using Grails, in
the UK the largest satellite broadcaster is Sky TV (owned by News
Corporation who also own Fox in the US) and they have ported the
whole of onto Grails. The Sky team have implemented a
non-trivial bespoke CMS author system on the backend which delivers
content that serves around 150 million requests per

In the US, Walmart’s equivalent of the Apple iTunes store
is written in Grails and I imagine gets quite significant traffic.
There are also other big names, like LinkedIn, as well as many,
many large corporations using it internally because of how easy it
is to deploy a Grails application onto existing Java based

Version 1.2 has just been
What is the focus of this release? What
are your top 3 features of this version?

There was a big focus on stability and performance in this
release. We have optimized the GSP rendering engine significantly
and it is good to see that Grails has strengthened its position as
the most performant dynamic language framework available. We’ve
also implemented many build infrastructure improvements such as the
ability to easily specify JAR dependencies with a dependency
resolution DSL built on Ivy.

GORM (the ORM layer built on Hibernate) has also seen
improvements with a new syntax for dynamic finders and the ability
to specify reusable named queries that can be merged with
additional criteria, making Grails querying a lot more DRY. On the
topic of keeping things DRY we have also added global constraint
and ORM mapping definitions so you can easily specify the default
behavior of GORM domain classes globally.

Other than that there are literally hundreds of smaller
features and improvements that are described in the release

What’s on the road-map for Grails?
 features are planned for the next major
version, and is there a time schedule?

We plan to do a pretty short iteration for Grails 1.3 in
order to introduce support for Groovy 1.7. That should be coming
around the end of March and will also include the ability to
publish and resolve Grails plugins against standard Maven
repositories for organisations who want to maintain their existing
Maven repository and not introduce a new repository format (which
Grails currently requires).

Moving on to Grails 2.0, the focus there is around
improving Grails modularity by extending it to runtime modularity
and the ability to start, stop and upgrade Grails plugins at
runtime without restarting the server. We will be exploring
different ways to achieve this in the second half of

Other than that, our main focus then is to keep Grails
stable and encourage the Grails plugin eco-system to grow. We have
several Grails plugins planned and it should be an exciting

Like many other successful software systems Grails
at its core, a plugin
functionality and extensibility through plugins.

Do you have an overview of how many plugins are currently
How many of them are
are the responsibility of the Grails team?

There are nearly 350 plugins hosted in the Grails central
and more hosted externally. The ones that are
regarded as the responsibility of the Grails team are the plugins
that ship with Grails (hibernate, tomcat and webflow, currently)
and those supported by SpringSource.

The quality and up-to-dateness of the plugin
varies greatly. Are there any plans

quality of plugins, or even

to create a certification
process for “trusted” plugins? 

The “trusted” plugins from SpringSource’s perspective is
those that we support. However, there are many other plugins that
are not supported but add significant value. There is certainly a
case for creating a certification program and it is something we
will be looking into in 2010.

Since last year, the Grails framework is part of
the SpringSource family.
What synergies are there
and how does the Grails community benefit from

I believe that the Grails community are starting to see a
far more connected story in terms of how SpringSource now has the
ability to offer a solution at each stage of the development
life-cycle from build (STS) to deployment (Tomcat / tc

In addition, because we have so much expertise on hand at
SpringSource we are able to turn around bug fixes much quicker as
the Grails team can openly collaborate with members of the core
Spring and Tomcat teams (amongst others). Grails also has far more
influence over the direction of the projects it builds upon. For
example, if the Grails team needs a particular feature in Spring or
Tomcat it is now easy to have those features implemented on

How intensive is the collaboration with other
SpringSource Teams?
Are there regular
and joint
release plans,
 or are you working more
the other Spring projects?

The teams are all fairly autonomous, but maintain constant
communication via regular meetings. Release planning is done
jointly among all projects, typically if you look at Grails 1.2 we
were dependent on the release of Spring 3.0 and hence had to wait
for Spring 3.0 to go GA before 1.2 could be released.

According to my
research, you still write the
biggest part of the Grails framework source-code by
How many active developers with submit
besidesyou, at the
Is there sufficient
or would you like to have more
support from the Grails community?

2009 was a pretty tough year economically for most
companies, but the Grails project was fortunate to get some
significant external contributions. Lari Hotari contributed the
ability to precompile GSP pages and the majority of the performance
improvements, whilst Luke Daley rewrote the testing infrastructure.
From SpringSource Jeff Brown and I provided the consistent
contribution necessary to deliver releases of the project,
something you don’t get when a project Grails’ size is maintained
part time.

So in that sense I feel the Grails project has had pretty
good support from the community in 2009 and I hope it continues in
2010. Looking internally, here at SpringSource/VMware we are hiring
and have positions on the Grails team to fill this year which will
result in the number of full time resources on Grails doubling in

Do you have
developers, wh
like to support the Grails framework? 

methodsof participation exist
what criteria
needs to be
metto become a

There are many ways to contribute, from submitting patches
to our issue tracker, to contributing a plugin, to simply answering
questions on the mailing list. To become a Grails committer we have
a process whereby we encourage those willing to contribute to do so
via Git pull requests and if enough requests of high enough quality
emerge we are open to granting commit access.

The Grails / Groovy team is distributed worldwide.
Head of
you are
responsible for development, 
promotion, consulting, reporting and
much more …
You must be pretty busy.
Could you please describe your typical
From what locations do you and your colleagues
How much time do you
reservefor actual coding on
the framework?

 I tend to mainly support SpringSource service
delivery (consulting, support and training) rather than getting
involved in those activities myself. This frees my time up to be
fully engaged with engineering activities, which during the week
involves working with our project managers to set goals and
deadlines, working on Grails issues, developing / designing new
Grails features and coordinating the Grails team (both internally
and externally). I would say I am 80-90% focused on engineering
activities and the rest on promotional / marketing activities
(speaking at conferences and user groups, working with the
Marketing team and writing articles) and/or supporting the service
delivery team.

My current working location is in Spain, others in the
Groovy/Grails team are in the UK, France, Germany and the

Have any operation
principles or obligations changed since the acquisition by

No, nothing has changed. VMware as a company are
incredibly understanding of the importance of development
communities and realize that the ongoing investment into the Spring
and Grails communities is critical. As I have already mentioned, we
are hiring on the Grails team so the impact of the acquisition has
only been positive.

What values does VmWare add as the parent

There is an incredible opportunity ahead of us at VMware
to create a seamless end to end virtualized environment for
developing and deploying applications. Development practices have
been significantly optimized over the past 5 years with the
emergence of frameworks like Spring and Grails, whilst operations
have remained largely unchanged. Work needs to be done
to provide the same levels of productivity gain in the operational
space so that people can be freed up to innovate. VMware and
SpringSource are in a unique position to provide an environment to
build, run and manage virtualized applications and you can expect
some pretty exciting products emerging in the near

A daring look into the future: Do
you have a vision for Grails in 2015?

Will you continue to be the
Head of

 Who knows what might happen in the future, I could
be hit by a bus! Seriously though, although we have come a long way
in optimizing development practices there is still much to be done
to provide further simplifications. In 2015, I see a Grails
persisting data to a NoSQL database, rendering Rich Internet
Applications and all running on a virtualized environment. See you

Graeme, thank you very much for your

comments powered by Disqus