Welcome back Grails

I started my journey with learning Java web-frameworks with Grails. That was really long time ago (around 2009) with Grails’ version 1.0.4. When I became full-time Java programmer I used Grails in several internal CRUD apps, but it was quick&dirty solution to provide basic functionality. My new job (I’ve just started) involves mainly programming with Groovy&Grails therefore I’ve decided to write a few posts about what is going on in Groovy&Grails world right now.

grails Before I start there is a big announcement. As Graeme Rocher posted on Twitter, new version of Grails (starting with number 3) will be totally new thing – based on Spring Boot and many projects around it. Therefore Grails being described here is going to retire in a predictable future. Just so You know.

The latest version of Grails which I am using is 2.4.3 with Groovy in version 2.3. In a following article I am gonna to point out some problems and interesting things I have discovered while ‘getting in touch’ with latest Grails.


Scaffolding is often presented as one of the most ‘groovy’ thing in Grails. The ability to quickly prototype working application is powerful feature and it was a place where I started my revisit. And right at the beginning I have encountered an subtle problem. Reference documentation says that there is a possibility to run such code:

class UserController {
     static scaffold = true     

And it should work with existing User domain class. I have given it a try but I was unsuccessfull. Why? Grails complained about missing domain class. What have I done wrong? The problem is with packaging – I have never liked examples using default package. With Grails it is even more problematic as there are separate folders for controllers, domain classes and so on. Therefore as I created com.wordpress.chlebik.grails.tutorial package inside domain folder, framework could not resolve proper path. The solution is simple – just use full class name.

class UserController {
     static scaffold = com.wordpress.chlebik.grails.tutorial.User

It works like a charm. It is also possible to use such code to enable scaffolding for a given domain class even from controllers with different name:

class AdminController {
     static scaffold = com.wordpress.chlebik.grails.tutorial.User

In my opinion Grails scaffolding is even better than it was with feature called static scaffolding. Back in 2009 scaffolding was interesting, but it was done as a ‘runtime magic’. There was no way to interact with generated sources (or it was not so easy). Right now we have static scaffolding which is scaffolding but with generated sources. Imagine creating simple domain class like User

class User {

    static constraints = {}
    String       firsrName
    String       lastName	
    String       email	

Using Grails console or IDE support we can invoke command:

grails generate-all User

which creates separate views (I mean GSP files) and controller with implemented methods. What is more cool, are test classes (based on Spock specifications) generated as well with testing logic within! So if You are not familiar with unit-testing – it is a great place to learn how it is done.


A few years ago my knowledge about TDD was almost non-existent. It has changed since then, therefore I welcomed Grails’ testing support pretty great. As I mentioned above, we can be given out-of-the-box tests methods with logic in them. Of course it is not what TDD is about, but it makes a good start to make changes and go further. What is more interesting is use of mixins. They provide simple way to link tested class with tests itseslf. What is more cool is use of Spock testing framework. I have to admit I have a problem with finding which plugin/core functionality provides Spock as a dependency. There is Spock Grails Plugin but I do not see any dependencies to it in plain configuration files.

But enough of it – we have Spock at our service, so using it is very simple. Just like this:

class UserControllerSpec extends Specification {

    def setup() {

    def cleanup() {

    void "test something"() {

If You are trying to run above test it is possible You get initializationError. Test method must atually test something – leaving empty method body is not an option!

We are given several implicit objects like request, response, controller, view to support controller testing. We can use very straightforward annotation @Mock – which just instantiates in-memory GORM which mocks all ORM-related calls. There is also possiblity to run integration tests, and what is even more cool – even more plugin for functional tests. Back in time there was only Canoo available, now new solutions like Selenium and Geb are also an option. It is hard to write here all about testing in Grails. I am planning to wrote more in separate posts.

Config options

Config files are still very neat way to tail application to our needs. What is the most important change since I last worked with Grails is added BuildConfig.groovy file, which was designed to separate configuration of build process and application config itself. What is more fabulous is logging configuration – so many customizing possibilities! To keep things short I am planning also some kind of post about it, but there is a nice place to start.

Asset Pipeline Plugin

As a Java programmer I am not keeping up with latest changes in HTML&CSS&JavaScript community. There has been tremendous progress in that areas lately (not to mention HTML5, LESS&SASS, writing MVP apps in JavaScript). Therefore creators of Grails are trying to simplify several things so they have switched from resources-plugin to asset-pipeline-plugin.

With previous approach, all resources put in web-app folder were just laying there waiting for the programmer to use them. It was a matter of view layer to include or exclude used resources. Right now plugin has possibility to include or exclude portions of CSS or JavaScript used on certain page. Another cool thing is ability to automaticaly apply changes in resources code while in development mode. there is a great Youtube video about it.

Static compilation

Somewhere by the road to Groovy 2.0 and Java 7 appeared static compilation and invoke dynamic. To make long things short – in a situation where You do not need dynamic Groovy features, it is possible to disable them and gain boost on performance. There are is nice blog post worth mentioning.


As I walk through the latest reference documentation I constantly see something new. It is hard to put everything in one blog post therefore I am planning several additional articles about latest Grails and Groovy combo. Stay tuned.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s