1. Getting Started
Traditional software development typically involves writing code, compiling code, running tests, and assembling an archive that finally gets deployed or distributed. As software projects became more complex, additional steps such as running static code analysis, conditional inclusions of resources, and running security scans have become part of the mainstream build and deployment process. Build automation tools allow you to automate these steps, which helps make builds repeatable and predictable. In this book, we will discuss and explore the features of Gradle, a popular build automation tool.
Gradle ( http://gradle.org/ ) is the newest addition to the Java build project automation tool family. It is open sourced under Apache License 2.0 and its first version (0.7) was released in 2009, followed by version 2.0 in 2014. At the time of writing this book, version 2.7 is the current version of Gradle. Gradle has been gaining a lot of adoption as it draws on lessons learned from other existing build tools such as Ant and Maven. Several high-profile projects such as Android, Spring Framework, and Hibernate have migrated their build systems to use Gradle. Lets look at some reasons for Gradles popularity.
Declarative Dependency Management
Most Java projects rely on other projects and open source frameworks to function properly. It can be cumbersome to download these dependencies manually and keep track of their versions as you use them in your projects. To make things more complicated, these dependencies might have their own dependencies (referred to as transitive dependencies ) that need to be resolved and downloaded.
Gradle provides a convenient way to declare your project dependencies. It then automatically downloads those dependencies (along with transitive dependencies) and allows you to use them in your projects. This simplifies project dependency management greatly. It is important to note that you only tell Gradle the what and not the how.
Declarative Builds
Gradle uses a Groovy ( http://groovy-lang.org/ ) based domain specific language (DSLsee https://docs.gradle.org/current/dsl/ ) for declaring builds. The DSL provides a set of language elements that can be easily assembled to create build scripts that are simple and clearly express their intent.
Build by Convention
Gradle provides sensible defaults and conventions for Java, Groovy, web, Scala, Android, and OSGi projects. For example, Gradle recommends that all the production source code for a Java project reside under the folder src\main\java . In the same way, it has recommendations for where the test code and resources should go. Additionally, default tasks get configured automatically for a Java project that would compile the code, and then run, test, and generate a JAR artifact.
Adhering to these conventions would make the build scripts very concise. However, you are not limited to follow these conventions. Since the Gradles DSL is based on Groovy, it is easy to write Groovy code to tweak and deviate from these conventions.
Incremental Builds
Complex projects often run into slow build times as the build tool tries to clean and rebuild everything. Gradle addresses this problem by providing incremental builds that skip the execution of a task if neither the inputs nor the outputs have changed. For example, the JavaCompile task takes a set of Java source files as input and generates a set of class files. Gradle uses this information to check if the source files have changed and if no changes are detected, the task gets skipped.
Gradle Wrapper
Gradle Wrapper is simply a batch file ( gradlew.bat ) in the Windows environment and a shell script for Linux/Mac environments. When it runs, the wrapper script downloads and installs a fresh copy of Gradle runtime on the machine and executes a Gradle build. Gradle Wrapper makes it easy to spin up new continuous integration (CI) servers that can run builds without any additional configuration. The wrapper also makes it easy to distribute code and collaborate with others, as the recipients can easily build it.
Plugins
Gradle makes it easy to augment and customize its functionality through plugins. Plugins are distributable components that encapsulate reusable build and task logic. Using plugins, it is possible to support additional languages, create new tasks, or modify existing task functionality and extend build language by adding new keywords. With Gradle, you can easily create your own plugins, thereby enabling you to integrate tasks and workflows that are specific to your organization.
Open Source
Gradle is open source and costs nothing to download and use. It comes with rich online documentation and the support of an active community. Additionally, Gradle Inc. offers consulting and commercial support for the Gradle ecosystem.
Gradle Alternatives
Before you dig deep in to Gradle, take a look at couple of its alternativesAnt + Ivy and Apache Maven.
Ant + Ivy
Apache Ant ( http://ant.apache.org ) is a popular open source tool for scripting builds. Released in 2000, it was the first among the modern build tools for the Java ecosystem. The framework is Java based and uses extensible markup language (XML) for its configuration. The default configuration file for Ant is the build.xml file.
Using Ant typically involves defining tasks and targets. As the name suggests, an Ant task is a unit of work that needs to be completed. Typical tasks involve creating a directory, running a test, compiling source code, building a web application archive (WAR) file, and so forth. A target is simply a set of tasks. It is possible for a target to depend on other targets. This dependency lets you sequence target execution. Listing demonstrates a simple build.xml file with one target, called compile . The compile target has two echo tasks and one javac task.
Listing 1-1. Sample Ant build.xml File
Ant doesnt impose any conventions or restrictions on your project and it is known to be extremely flexible. This flexibility has sometimes resulted in complex, hard-to-understand and maintain build.xml files.
Apache Ivy ( . Integrating Ivy with Ant involves declaring new targets in the build.xml file to retrieve and resolve dependencies.
Listing 1-2. Sample Ivy Listing
Maven
Apache Maven is currently the most popular build automation/project management tool in the Java ecosystem. Released in 2004, Maven attempted to address many problems faced by Ant users. It adheres heavily to convention over configuration and introduced standard directory structure to projects. It also introduced declarative dependency management and automatically downloaded needed dependencies from external repositories.
Maven uses XML for providing project, dependency metadata, and build configuration. This information is provided in a pom.xm l file defined at the root of the project. Listing shows an example pom.xml file for a Java project.
Listing 1-3. Sample pom.xml File
http://maven.apache.org/POM/4.0.0 "
xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance "