Tim Berglund - Building and Testing with Gradle

To my son, Zach, who plays the trumpet

Psalm 150:3

Tim Berglund

This book is dedicated to my entire extended family who, in numerous ways, facilitated the creation of this first of many books. To my beautiful and supportive wife Madelaine for allowing me long nights of typing and days of constant Gradle talk. My daughters Scarlette and Violette for playing rounds of Angry Birds while I made on-the-road commits to the book. My brother Jordan for promoting Gradle in his circle of Denver developers and supporting my photographic imagery needs in Gradle educational materials. And my parents Terry and Marylyn for bearing the laptop coming out even at dinner whenever a few more paragraphs could be composed.

Matthew McCullough

When I started writing Java code in 1996, there werent many options for compiling and building a project outside of javac and a custom build script. In those days, many of us with a background in C configured makefiles to build Java, because thats what we knew. The challenge with this approach was that the idiom of make and the model it defined didnt reflect the Java world very well. Many teams would resort to creating a shell or batch script to build their project, so there was a huge vacuum at this time for a tool that would provide platform independent building and packaging. The first tool to provide a successful solution to this problem and to realize significant adoption was Ant. Ant provided a way to describe a Java build that was extensible and platform independent, which was a large part of its success. Some of the downsides of Ant were its verbosity, its lack of conventions, and its lack of dependency management. These deficiencies led to another popular tool, Maven, to be adopted by a number of development teams.

During the same timeframe, the industrys maturity was growing in the area of software engineering discipline. Many of these disciplines were captured in the Agile Manifesto and in the spirit of Extreme Programming. These led to many changes, including more frequent builds on machines other than the developers workstation, often on different operating systems. Many teams discovered that a successful compile was just a small measure of the quality of a project, leading to an increased demand on the build system, including unit and integration testing, static analysis tools such as FindBugs, and code coverage analysis. This resulted in new build system pain points that needed to be addressed. Instead of revisiting the model of the build tool, the common solution was to create plug-ins to existing build systems. The continued growth in software engineering maturity today can be seen in the DevOps movement, climaxing with the publication last year of Jez Humble and David Farleys book Continuous Delivery (Addison-Wesley). The discipline of continuous delivery encourages us to ask: how fast can we move a newly coded idea from development into production? The solution to the challenges of continuous delivery is automation.

What I have discovered over the years as a software engineer is that in order to solve a problem best, I have to understand the model. The reason make wasnt a great build tool for Java is that it didnt have a way to express the model well. Ant gave us platform independence and a better vocabulary, but a weak model. Maven provided a stronger model, which is why so many people prefer it over Ant. The challenge for Maven is that it provided the one model to rule them all. Youre able to express your build needs within that model and only that model.

Gradle fills this gap. Gradle provides a way of modeling a build system using a DSL with convention over configuration, yet allowing an enterprise to define its own model. It goes deeper than this, as explained in this introductory book by Matthew and Tim, but modeling by convention is truly a game changer for enterprise software development.

I was excited to see that this book was being written by Matthew and Tim. Matthew has a tremendous amount of experience in the software automation space, with years of practical hands-on consulting experience with Maven and being the top go-to guy for Git training. Tim has been one of the top practicers and trainers in the Groovy and Grails space for years. Together, they bring a tremendous amount of experience in software development and software automation to this book. Additionally, Ive known both these guys as part of the No Fluff Just Stuff software conference series, in addition to many other conferences, and I can attest to them being top-notch speakers, teachers, and trainers. Tim and Matthew have a fantastic capacity to know very low-level technical details and can share that information with others in a very approachable way, which I feel is reflected well in this book.

This book is the first book to be focused solely on the subject of Gradle. As one who is convinced that this technology is a game changerso much so I joined the company behind it!Im convinced it will be well worth your time to understand and know this technology. I cant think of better people to write it than Matthew and Tim, and I know youll agree. May your builds always succeed!