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.
As Head of Grails Development for SpringSource, Graeme Rocher is the project lead and co-founder of the Grails web application framework. He’s a member of the JSR-241 Expert Group which standardizes the Groovy language. Graeme authored the Definitive Guide to Grails for Apress and is a frequent speaker at JavaOne, JavaPolis, NoFluffJustStuff, JAOO, the Sun TechDays and more. Graeme joined SpringSource in late 2008 upon the acquisition of G2One Inc. Before founding G2One, Graeme was the CTO of SkillsMatter, a skills transfer company specializing in open source technology and agile software development, where Graeme was in charge of the company’s courseware development strategy and general technical direction.
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 2009.
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 increatingthe 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 profits.
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 used and very successful framework. The ‘unique selling point‘compared with other Java-based frameworksis the very small development effort for implementing sophisticated web applications. Can you share some insightsintopublic projects thatare impressive in terms of their 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 Sky.com 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 month.
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 infrastructure.
Grails Version 1.2 has just been released. 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 notes.
What’s on the road-map for Grails? What 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 2010.
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 year.
Like many other successful software systems Grails is, at its core, a plugin systemwhichachieves functionality and extensibility through plugins. Do you have an overview of how many plugins are currently available? How many of them are so-called‘core-plugins,‘which are the responsibility of the Grails team?
There are nearly 350 plugins hosted in the Grails central repository 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 tomeasurethe 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 this?
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 Server).
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 demand.
How intensive is the collaboration with other SpringSource Teams?Are there regular meetings and joint release plans, or are you working more independentlyfrom 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 yourself. How many active developers with submit statusexist besidesyou, at the moment? Is there sufficient support, 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 2010.
Do you have recommendationsfor developers, whowould like to support the Grails framework? What methodsof participation exist and what criteria needs to be metto become a ‘Grails-Submitter‘?
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. As ‘Head of Grails‘you are responsible for development, coordination, promotion, consulting, reporting and probably much more … You must be pretty busy. Could you please describe your typical workingweek? From what locations do you and your colleagues work? 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 US.
Have any operation principles or obligations changed since the acquisition by VMWare?
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 company?
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 future.
A daring look into the future: Do you have a vision for Grails in 2015?
Will you continue to be the ‘Head of Grails Development‘in 2015?
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 there!
Graeme, thank you very much for your time!