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

BUILD SUCCESSFUL

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

BUILD SUCCESSFUL

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.

Using GitHub behind a proxy

At my customer, we are using a proxy server, and sometimes it’s handy to have access to GitHub, for example to the Grails repository, or my own Grails Fitnesse repo. I struggled a while to get this to work, but apparently, it couldn’t be easier:


export HTTPS_PROXY='http://10.0.0.1:3128'
git clone https://bodiam@github.com/bodiam/grails-fitnesse.git

Using the https protocol, you can commit your changes over https instead of using the git protocol, and it’s still really fast.

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!

Printing output in Grails 2.0 ant scripts

When developing plugins, in my case the Grails Fitnesse plugin, it’s sometimes handy to produce output to the user. In my case, I had a use case to give the user some information that Fitnesse had started up succesfully, and wanted to indicate the location Fitnesse was running on.

In previous versions of Grails (1.3.x), you could do ant ant.echo. However, as described in the Grails 2.0 release notes, the ant.echo doesn’t work anymore, and you’ll have to use ‘alternative mechanisms for output’.

Well, Spring Security Core had this already figured out. Just send a StatusUpdate event, which will be printed to the console automatically.

This be handy in the future for other plugin developers.

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:

Friday Repost: Grails and Bamboo

The Friday Repost series are copies from my earlier writings. Since I don’t want to loose them, and they might prove useful to others, I’m reposting them on this blog

In our development environment, we use the complete Atlassian suite. We (or actually I) choose this environment because the products integrates so well together, but also because it integrates good with other products, like SpringSource Tool Suite, or, in our case, IntelliJ IDEA. And finally, the Atlassian suite has excellent support for building Grails projects, which, at the moment, is all we do. Simply put, we choose Atlassian because it rocks!

To integrate even better with the Atlassian Build Server (Bamboo), I’ve created a small script which will update the version number of the application with the Build Number. This way, we always know which build is running where. To do so, I created the following script.

This script will look for a file called ‘build-number.txt’, which is produced by the Build Number Stamper Plugin, and put in the working directory. This file is read by the script, and it updates the version number in application.properties, which will result in a war file produced by the build in the following format ‘..war’, for example ‘todolist.0.1.34.war’. This way you can easily relate each build which bugs you might find, and avoids confusion, for example between testers and developers.

As an extra, we’ve show the current version of the application in the source of our HTML. We do this by reading the version number from the application.properties with the following tag:

This will display the version number of the application, and will allow you to relate issues to a build number, to avoid miscommunication about the deployed application!