The first build tool to grab a significant amount of developer mindshare in the Java ecosystem was Ant. Quite a long time later (relatively) came Maven and now, we have Gradle. Volumes have been written comparing Gradle to Maven and Ant, i.e. using Gradle to build your simple to complex project, but little has been written about using Gradle for automation. I’m here to change that.

Gradle is a fantastic tool to use in automation projects. This will be a series of articles written to explore various ways that Gradle can help in automating tasks, culled from two recent projects where we’ve done just that.

By way of introducing Gradle, I’ll start with the biggest selling point for automation projects: Groovy. Groovy has developed into an excellent language in it’s own right, runs on the Java platform, and enjoys a high function to low ceremony ratio. This in combination with the Gradle DSL makes Gradle a great choice for automation projects, when you want “what” you’re doing to shine through “how” you’re doing it.

So what type of automation am I going to show you? All kinds. The first automation project I used Gradle for was a “build” project gone wild. The product was a client-side only GWT application deployed to a CD/DVD for offline distribution. I started with a simple Gradle script to build the GWT application and decouple the build process from the IDE. After that was solved, I started thinking ..

1. 1.The GWT artifacts (HTML, JS, CSS) were built, now I have to
   

2. 2.Mount the CD/DVD image file read/write so I can update the GWT artifacts
   

3. 3.Delete the old application files, copy over the new ones
   

4. 4.Modify the file icon for the launching page (Home.html) and create a new shortcut from the root of the CD/DVD (broken every time Home.html is replaced, thanks OS X)
   

5. 5.Copy over the PDF files for the product (600MB+ - hence the offline distribution)
   

6. 6.If the client was providing updated PDF files, then I needed to
   

7. 7.Generate an XML file with the PDF file names and associated author names
   

8. 8.If the client was providing updated data files for the GWT application, then I needed to
   

9. 9.Extract the data from Excel
   

10. 10.Generate some more XML for one of the spreadsheets
    

11. 11.Generate some JSON for another one of the spreadsheets
    

12. 12.Make sure the updated data files (XML + JSON) were in the GWT application’s /public/data/ directory
    

13. 13.If the client provided an updated logo art for the CD/DVD, then I needed to
    

14. 14.Generate 31 frames of an animated graphic from the logo (logo + spinning throbber)
    

And on, and on ... these were all things that I had been doing manually since the first time I created this CD/DVD product years ago. I had pseudo-automated some of the steps ... mounting/unmounting, copying, generating an ISO from the disk image, etc. Mainly the pieces that involved complicated command line fu that was hard to remember a few months later - I copied those commands into a text file that I saved with the project so I could easily copy/paste them as needed. Hence pseudo-automated.

Enter Gradle. This project was my first “major” incursion into Gradle-land, so I was expecting some learning curve. Surprisingly, there wasn’t really that much. I spent probably a grand total of 10 hours over the course of a few days and walked away with essentially a fully automated CD/DVD production script of this custom GWT offline application. Gradle’s expressiveness and Groovy’s low ceremony were key players in this fairly flat learning curve.

I had intended to start this first article in the series with some digging into Gradle, but this post is already getting a bit longer than I wanted, so we’ll call this one baked and we’ll dig into Gradle first thing in the next post. Thanks for reading and if you’ve used Gradle outside of a build role, drop me a line - I would love to hear about it!

(p.s. sorry - comments are disabled, working on getting them re-integrated with my site)