Gradle in Action

Benjamin Muschko is a senior software engineer with more than 10 years of experience in developing and delivering business applications. He is a member of the Gradleware engineering team and the author of several popular Gradle plugins.

foreword
preface
acknowledgments
about this book
about the cover illustration

Part 1 Introducing Gradle
Chapter 1 Introduction to project automation
Life without project automation
Benefits of project automation
Types of project automation
Build tools
Java build tools
Summary
Chapter 2 Next-generation builds with Gradle
Why Gradle? Why now?
Gradle’s compelling feature set
The bigger picture: continuous delivery
Installing Gradle
Getting started with Gradle
Using the Command line
Summary
Chapter 3 Building a Gradle project by example
Introducing the case study
Building a Java project
Web development with Gradle
Gradle wrapper
Summary

Part 2 Mastering the fundamentals

Chapter 4 Build script essentials
Building blocks
Working with tasks
Hooking into the build lifecycle
Summary
Chapter 5 Dependency management
A quick overview of dependency management
Learning dependency management by example
Dependency configurations
Declaring dependencies
Using and configuring repositories
Understanding the local dependency cache
Troubleshooting dependency problems
Summary
Chapter 6 Multiproject builds
Modularizing a project
Assembling a multiproject build
Configuring subprojects
Individual project files
Customizing projects
Summary
Chapter 7 Testing with Gradle
Automated testing
Testing Java applications
Unit testing
Configuring test execution
Integration testing
Functional testing
Summary
Chapter 8 Extending Gradle
Introducing the plugin case study
From zero to plugin
Writing a script plugin
Writing custom task classes
Using and building object plugins
Summary
Chapter 9 Integration and migration
Ant and Gradle
Maven and Gradle
Comparing builds
Summary

Part 3 From build to deployment

Chapter 10 IDE support and tooling
Using IDE plugins to generate project files
Managing Gradle projects in popular IDEs
Embedding Gradle with the tooling API
Summary
Chapter 11 Building polyglot projects
Managing JavaScript with Gradle
Building polyglot, JVM-based projects
Other languages
Summary
Chapter 12 Code quality management and monitoring
Integrating code analysis into your build
Measuring code coverage
Performing static code analysis
Integrating with Sonar
Summary
Chapter 13 Continuous integration
Benefits of continuous integration
Setting up Git
Building a project with Jenkins
Exploring cloud-based solutions
Modeling a build pipeline with Jenkins
Summary
Chapter 14 Artifact assembly and publishing
Building artifacts and distributions
Publishing artifacts to a binary repository
Publishing to a public binary repository
Artifact assembly and publishing as part of the build pipeline
Summary
Chapter 15 Infrastructure provisioning and deployment
Infrastructure provisioning
Targeting a deployment environment
Automated deployments
Deployment tests
Deployment as part of the build pipeline
Summary


appendix A Driving the command line
appendix B Groovy for Gradle users

index

»The authoritative guide.« Hans Docktor, Founder of Gradle and Gradleware

»A new way to automate your builds. You'll never miss the old one.« Nacho Ormeno, startupXplore

»The best Gradle reference ever! Full of real-world examples.« Wellington R. Pinheiro, Walmart eCommerce Brazil

»Required reading for the polyglot programmer!« Rob Bugh, ReachForce

»The missing book to help make Gradle accessible to any developer.« Samuel Brown, Blackboard, Inc.

When you create a new technology like Gradle, one of the most critical stages of development has nothing to do with writing code. Once the initial versions of your project are used by thousands of developers and a community starts to assemble around it, the challenge becomes communicating with a much larger audience of users who will use the project and pass judgment on its merits, and growing the size of the community ten-fold or a thousand-fold. Gradle has already amassed a large audience, and we’ve seen tremendous growth over the last two years, but we’re getting ready for a still larger influx of end-users. Therefore, the importance of having a good book cannot be overstated. Developers with a range of skills and abilities need to be able to pick up a book that’s easy to understand and which can impart both the syntax and the philosophy behind the tool. Only then will they be able to confidently grow the community that can educate itself using a single, authoritative reference for Gradle. Gradle in Action is that book. Additionally, this book gives new Gradle users a very good glimpse into how Gradle fits into a larger view of continuous delivery. Benjamin is the sort of expert that you hope emerges from an open source community. He has been a long term Gradle contributor and is the author of several popular Gradle plugins. He’s both a communicator and a developer. Benjamin has the rare ability to dive into the core details of a particularly challenging development problem and then explain the tool to end-users. We’re happy that he has recently joined Gradleware and is now part of the Gradle development team. I hope you enjoy the book as well as working with Gradle. May your software delivery process become both fun and efficient. HANS DOCKTER FOUNDER OF GRADLE AND GRADLEWARE 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. 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 religiously2 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. 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.