Preface
When I started my career as a software developer, I was blissfully unaware of the need for project automation. My tool of choice was the IDE, which allowed me to run all tasks required to fully automate my software development cycle. In 2003 Rainer Sawitzki,[1] an external consultant to the project I was working on, introduced me to Apache Ant. I thought it was the most amazing thing to be able to describe my automation logic with the help of mostly pre-existing functionality and to execute it in a defined order. Despite the fact that the definition language was XML (these were the days when XML was still fashionable), I soon began to become more ambitious by creating artifacts for different target platforms, writing deployment logic for web containers, and setting up a continuous integration server.
1 Thanks again for the object-oriented mindset I picked up by working with you. You’ve been a great mentor to me.
Automation requirements have changed significantly since then. My projects have grown in size and complexity. Deployment and delivery models have become far more sophisticated. And while I explored other build tool options to meet these needs over the years, I found that there was always a Catch-22. Many developers accepted the status quo in this space, which left them with painful experiences. Rarely is there a topic that’s discussed more religiously[2] than the pros and cons of build tools and why people hate them so much. The purpose of this book isn’t necessarily to convince you to switch your current build to Gradle. If you’re happy with your setup (whatever you’re using), by all means, stick to it. I will, however, talk about the massive innovation that Gradle brings to the table and compare it to existing solutions. I invite you to be your own judge.
2 This topic is on par with Windows versus Linux or the comparison of web application frameworks.
I started to write this book with a specific goal in mind: teach the core concepts of Gradle, but don’t stop there. In a world that embraces software development practices like continuous integration and delivery, you have to take into consideration the tooling ecosystem into which a build system must integrate. Hopefully, I’ve found the right balance in this book. If you have questions, comments, or ideas, I’d love to hear them. Your feedback might spark the urge to write a second edition or add-on content. Feel free to send me an email or contact me on the book’s forum at Manning.
As with all book projects, the page count is limited. To stick to the scope of this book, I had to leave out some of the content I initially planned to write. (This is my first book. With the naiveté of a virgin author, I thought I could fit it all in.) The source code repository of the book, found at https://github.com/bmuschko/gradle-in-action-source, expands on some of this material and lists references to other code examples and resources. I hope you enjoy reading the book as much as I enjoyed writing it.