Learnings of writing Groovy in Action, Second Edition

More than two years ago, I wrote about the effort to revive Groovy in Action. Little did I know that it would take another 2 years of a huge combined effort to get the book out. Maybe not surprising for other authors, and it has been mentioned many times before, but yet; it was an effort. It was quite a time-consuming process to write a book, coordinate with your co-authors, the editors and the publisher, while also keeping in touch with you, the reader, who come up with a lot of greats ideas and publish errata on the forums.

But, having mentioned the effort, it’s such a rewarding effort to finally have finalised the book! If feels like I can finally check one the things on my bucket list, and that is to have my name on the cover of an amazing book. And while I’m very biased, I’m pretty sure this is not only the best on Groovy, it’s also a great book on learning how to program. Topic like functional programming, using collections, testing your software, and more advanced topics like ASTs, creating DSLs, etc are all covered in the book, and provide a great help for beginners in programming as well as advanced software developers.

While writing the book, I’ve learned a lot. Not only about the Groovy programming language, and how to convey our message to our audience, but also about the writing process and the technologies used to write the book. For example, we are using GitHub to store the book, which is a perfect way of keeping track who worked on what, restore versions, etc. However, the book is written in Word. Which is probably the single most horrible way to write a book in. Don’t ever do this! Instead, choose a more open format like AsciiDoc, which is a text document format for writing notes, documentation, articles, books, ebooks, and much more. AsciiDoc can easily generate EPubs and PDFs, while writing in plain text, which is an ideal format for Git. Find a publisher which supports plain text publishing, and preferably AsciiDoc!

Secondly, writing with a (distributed!) team of software developers, who all have limited time due to their family life and their 40 hour workweek, is hard. Coordinating, keeping a focus, it’s hard. When you embark on such an adventure, do a brainstorm session. Create a backlog, keep track of who is working on what, and find a good way of communicating with your team members. Gitter might be such an option, or Google hangout, but in reality, nothing beats being together and having a face to face talk about the progress of your book. It’s not absolutely mandatory, but it helps quite a lots.

Thirdly; keep a focus while keeping the pace. Quality matters a lot, but so does delivering. The first version of Groovy in Action covered Groovy 1.0. The Second Edition originally covered 1.8, but then Groovy 1.9 came out. And then 2.0. So we had to check all the code examples, which, fortunately (and I can really recommend doing so) could be executed automatically. In the end, Groovy 2.4 was covered, which is great for the community, since it being the most recent version of Groovy, but tough on your writing crew. And mostly thanks to the endless energy of Paul King, you can now all enjoy the hard work we’ve put into the 912 pages of Groovy code.

While there are many more things to learn from such an experience, the three lessons above proved to be the most important for me. And while many things could have been done much better, in the end, it’s the results that matter, and difficult roads often lead to beautiful destinations. I think that I speak for the whole Groovy in Action team while I say that we are proud of the result, and we’ve produced a quality product for you to enjoy. I’m proud to have been able to produce such a book, and to have been given the trust of our publisher as well as our audience to deliver the quality you expect us to deliver. I thank you for your patience and your support in delivering this book. We couldn’t have done it without you! Thanks!

Groovy in Action Second Edition PDF and Paper

Only 4 days ago, the paper version (pBook) of Groovy in Action was released, and with the release of the electronic edition (PDF, epub and mobi), all the editions of Groovy in Action, Second Edition, are fully available! So, what’s exactly covered in the book?

The book is divided into three parts. The first part of the book is about the Groovy language. The second part is about working with the Groovy library, while the third part dives into applied Groovy, showing you some best practices around tests and some other frameworks closely related to Groovy.

In the first chapters, the Groovy Basics are covered. The Groovy basics, as the name implies, covers the foundation of Groovy and gives a great start to grasp the language. This chapter is followed by the Groovy Datatypes and Collections, which really show the power and flexibility of Groovy, and showing the start of learning how to use functional programming with the Groovy programming language. This is completed by introducing Closures, one of the core language elements of Groovy. The chapters after this make the first part actually already a complete book, and we could have stopped there if we wanted to limit ourselves to the language only. But the reasons which make Groovy such a compelling choice is not only the flexibility of the language, but also the ecosystem around it.

So, in the second part of the book, the Groovy library, covers technologies like the working with the GDK (the methods added to the JDK by Groovy), Database programming (covering SQL as well as NoSQL databases), XML, JSON, Webservices, and a full chapter packed with tips on how to integrate Groovy into your current software pipeline.

To finish off, the 3rd part of the books (and we’re already 600 pages into the book by now) covers the focus of my work for the last 10 years, which is software testing. A lot of that knowledge has been put into the Groovy book, and I really hope it will prove useful in increasing the quality of your software. Besides testing software, concurrency, always a complex topic, and DSLs, which for me, is one of the most interesting chapters in the book, since it brings a lot the previously covered chapters together and shows some real world examples on how to build your own DSL.

I’d like to thank my co-authors from who I learned a lot about writing Groovy in Action, as well as the Groovy languagehor! We really hope you’ll enjoy reading the book as much we had fun writing it, and if you have feedback, comments or compliments, let us know, we love to hear from you!

The curious case of Grails’ generate-all

I’ve been using Grails for some years now, and my normal workflow is something like: grails create-app, followed by creating some domain class, followed by a a grails generate-all, and a grails run-app. It helps greatly in selling Grails, and people are usually quite impressed by the speed of having an up and running hello-world application in Grails.

However, since Grails 2.3.0, this is not the case anymore. The Grails scaffolding is now a separate plugin, and while that’s not bad per se, it is bad that it’s a compile time plugin. The compile time means that the plugin is only added to the project whenever a compile time target is used, and personally, I only get into the compile time whenever I do a run-app. And yes, you’re right, that’s after the generate-all, which, as you might have guessed, doesn’t work in Grails 2.3.0 before having run a compile target (and, not coincidentally, grails create-domain-class is such a target…)

So, should you run into this, running grails compile, even though it’s functionally not needed, solves your issues.

Upgrading Grails 2.2.4 to 2.3.0

I’m currently working on a trivial Grails application, running on Grails 2.2.4. However, two days ago, Grails 2.3.0 was released, providing many new features, like testing with Spock by default, Hibernate 4, etc. However, when upgrading to 2.3.0 using

I received the following error:

I turns out grails upgrade doesn’t fix this for you (Thanks Tim!) (and, starting from Grails 2.3.0, it’s deprecated and replaced by use-current-grails-version), and you need to fix this yourself. It turns out the fix is quite easy; just add replace your Tomcat and Hibernate dependencies by this:

And it will work. Hope it’s useful, and remember to carefully read the docs, I missed it.

Update (14-10-2013): If you are wondering why debugging doesn’t work: you’ll need to start Grails with run-app --debug-fork
IntelliJ Update (1-10-2013) : IntelliJ 12.1.5 has been released, which now has support for Grails 2.3.0.
If you are using IntelliJ (12.1.5 EAP at the moment), you’ll find out that it’s not compatible with Grails 2.3.0. There’s an issue for that, which has been fixed. Applying the patches from the Youtrack issue will fix the issue and will make Grails 2.3.0 working on IntelliJ 12.1.5.

Gradle: displaying artefact locations

Gradle’s output, unlike verbose build tools like Maven, is very terse. In my opinion, a bit too terse. For example, when running gradle jar, this is the output:

:epub-organizer-core:compileJava UP-TO-DATE
:epub-organizer-core:processResources UP-TO-DATE
:epub-organizer-core:classes UP-TO-DATE
:epub-organizer-core:jar UP-TO-DATE
:epub-organizer-dropwizard:compileJava UP-TO-DATE
:epub-organizer-dropwizard:processResources UP-TO-DATE
:epub-organizer-dropwizard:classes UP-TO-DATE
:epub-organizer-dropwizard:jar UP-TO-DATE


Total time: 13.752 secs

Okay, that’s nice, looks good, but now what? Where’s my jar? Remembering that it’s produced in build/libs is easy, but a less frequently used task like distZip will produce it’s artefacts in a different location, so you’ll have to remember those locations to. Luckily, Gradle is a very flexible build tool, and with the help of my friend Marcin Erdmann, we came up with the following Gradle script, which you can put in ~/.gradle/init.gradle, or as I did, in my build.gradle file. If you put it in your init.gradle file, please be aware that you’ll have to remove the ‘gradle.’ prefixes.

After each build, the following will now be produced:

:epub-organizer-dropwizard:classes UP-TO-DATE
:epub-organizer-dropwizard:jar UP-TO-DATE


Total time: 13.752 secs

Output location: /Users/erikp/User Files/Projects/epub-organizer-gradle/epub-organizer-dropwizard/build/libs/epub-organizer-dropwizard-1.0.jar

Still pretty terse, but quite useful anyway.

Jacoco code coverage with Gradle

One of the new features of Gradle 1.6, the Groovy based build tool, is Jacoco support. Jacoco is one of the few (only?) Open Source code coverage tools still in active development, and starting from Gradle 1.6, it’s now a supported plugin. Enabling the task is easy, just add

to your build.gradle, and run ./gradlew jacocoTestReport and it.. does nothing. For those running into the same issues, this might save you a bit of time:

After a bit of searching, it turns out the Jacoco plugin is a bit broken. When using it with a Java project, as I’m doing, you need to do a couple of things to enable it, but also then, it unfortunately doesn’t work as advertised, though the fix seems not to complex.

First, you need to enable the following:

And then, instead of running ./gradlew jacocoTestReport as mentioned in the docs here, you need to run ./gradlew test jacocoTestReport. Unfortunately, no location is printed where the documentation is created, so no clickable links in your terminal, but you can find it under build/reports/jacoco/test/html/index.html. Well, that wasn’t so bad now, was it? Have fun!

More resources

For more information about using Jacoco and Gradle, you can checkout the following resources:

Creating projects with Gradle

Coming from a Maven background (Maven 1, 2, 3), I find it a bit strange that Gradle doesn’t provide archetypes like Maven does. There’s a template plugin, which helps a little, but besides that, you’re out of luck. Or are you?

I found a pretty neat Gradle script in their Jira system, which can create a directory structure for you even when working on a Groovy or Scala project. The easiest way to do so is to add the following ‘initProject’ task to the Gradle build.gradle:

You can call it by executing the following command:

This works great until Hans or Luke decide to create the

command, which would make our lives even easier!

Reviving Groovy in Action

Groovy in Action Second EditionSome time ago, Dierk Koenig decided to write Groovy in Action, THE bible for learning the Groovy language and some libraries around it. The book was written for Groovy 1.0, and it was a great reference (I learned my first Groovy from that book), and though outdated, it still is a great book. Then, some years later, Groovy 1.5 came out. So it was time for an updated version of the Groovy in Action book, now the second edition. So, the musketeers got back together and investigated what the new features were, made some split who would write about what, and off they went. Only forgetting one small thing: this was not their only project on hand. So, sometimes the musketeers wrote some, sometimes they provided food for their family, sometimes they rested a bit. While time passed on, Groovy 1.6 came out. And even 1.7. And 1.8. And 1… well, 2.0 actually.

When Groovy 2.0 came out, not a lot of things had happend on the book. Sure, there were new some new chapters written, but there were also still 18 other chapters to write. So it was time for some Action. So, some time ago, just before a Grails Exchange far away, yours truly wrote Dierk, and with the famous words: “hee Dierk, what is going on with the book?”, was he invited in joining the musketeers. Ha, he thought, this is my chance on fame and fortune! So imagining the screaming fans, the fireworks, the rains of golden coins, I signed the contract with my blood, and joined the party. And what a party it was. It was more like a pack of brigands than the musketeers! Ohohoh, what had I signed up for? So, when the Grails Exchange really came, a chat with Guillaume was needed. So we did, after a great chat, some great ideas, and full of energy, we parted and… Nothing happened. All the things I had to do, for all the great ideas we had, I did nothing. Also I was to busy to get things going! But then, a voice from the sky came, which got us all by surprise. It was our great publisher, Manning, demanding progress. And he got it.

So, after almost one year of inactivity, a great motivation, and a lot of talks, we published a new version of the Groovy in Action MEAP! There’s an updated chapter on the GDK, created by yours truly! So no, the project is not dead. Really, trust us when we say we’re working hard, really hard, on finishing this great book! We’re all heavily motivated in delivering THE best book on Groovy, so no, the project is not dead, it was merely in hibernation, and yes, we will deliver this book. It will still take a bit of work, but another chapter is just finished (another one by me, this time about Groovy and Testing), with features about Spock, Gradle and many other improvements, and other chapters will follow soon. So keep spamming the forums, keep spamming the authors, keep us sharp, and shout your interested. We will deliver!

Grails in the Cloud – NLGUG meetup

At Tuesday, May the 8th, The NLGUG is organising a new meetup about Grails in the Cloud.

The meetup will consist of a talk by Maikel Alderhout, who is an expert on the topic, and will be followed up by Pair Deploying, in which pairs will deploy an existing Grails application to a PaaS of their choice, for example CloudBees, CloudFoundry, Heroku, OpenShift or JElastic.

The meetup is free, and will be kindly hosted by Quince, who will also be providing food and drinks! So if you want to join, checkout the meetup page and join us!

Testing Command Objects in Grails 2.0

In Grails 2.0, you need to use mockCommandObject to test command objects. However, what the Grails documentation doesn’t mention is how to use the mockCommandObject method. The mockCommandObject method is located in the ControllerUnitTestMixin. To use the method, you can use the following example:

This is a little inconvenient if your class needs a lot of properties. To make things a little easier, you can mock the command object in the setup method (using JUnit’s @Before annotation), and use the default constructor (with Map support), as you would normally: