Building and Testing with Gradle

Chapter 1. Hello, Gradle!

Ant and Maven have occupied opposing positions on the build continuum, to the benefit and detriment of their users over the past decade. Ant chooses to offer extreme flexibility to the user, imposing no conventions whatsoever, and not wanting to impose any heavyweight dependency management infrastructure on the build. Apache Ivy later added badly needed dependency management to Java builds, but still didn’t address the lack of conventions inherent in Ant. Maven, on the other hand, offered rigid standards and support for dependency management, but its standards were often overbearing, and deviating from them often proved more difficult than expected.

Ant and Maven have shared considerable success in the Java marketplace, despite important shortcomings in both tools. On the one hand, Gradle presents itself as a sensible middle ground between both extremes, offering thoughtful conventions for your build to follow, and making it easy for you to extend or redefine those conventions when you want to. Gradle provides out-of-the-box build conventions and at the same time realizes that no one set of standards can accurately reflect every build. Gradle therefore intends to be a means of developing organization- and project-specific build standards. It is best thought of not as a set of opinions on build standards, but as a toolkit for developing and extending those standards with a rich, descriptive language.

Gradle also gives you options in the way it handles build ...