List of Figures

Chapter 1. Introduction to project automation

Figure 1.1. On-demand builds execute build definitions backed by a VCS.

Figure 1.2. Build triggered by a check-in of files into VCS

Figure 1.3. Scheduled build initiated at 5:00 a.m. daily

Figure 1.4. A common scenario of tasks executed in a predefined order

Figure 1.5. DAG representation of tasks

Figure 1.6. The build file expresses the rules of your build expressed by tasks and their interdependencies.

Figure 1.7. Task inputs and outputs

Figure 1.8. The build engine translates the rule set into an internal model representation that is accessed during the runtime of the build.

Figure 1.9. The dependency manager retrieves external dependencies and makes them available to your build.

Figure 1.10. Ant’s hierarchical build script structure with the elements project, target, and task

Figure 1.11. Hierarchical project structure of sample Ant build script

Figure 1.12. Maven’s default project layout defines where to find Java source code, resource files, and test code.

Figure 1.13. Maven’s most important build lifecycle phases

Figure 1.14. Maven’s interaction with Maven Central to resolve and download dependencies for your build

Figure 1.15. Modularized architecture of a software project

Chapter 2. Next-generation builds with Gradle

Figure 2.1. Gradle combines the best features from other build tools.

Figure 2.2. Comparing build script size and readability between Maven and Gradle

Figure 2.3. Gradle’s compelling feature set

Figure 2.4. Build scripts apply the Gradle DSL and have access to its deep API.

Figure 2.5. In Gradle, Java projects are build by convention with sensible defaults. Changing the defaults is easy and achieved through convention properties.

Figure 2.6. Gradle provides deep integration with other build tools and opens the door to gradually migrate your existing Ant or Maven build.

Figure 2.7. Stages of a deployment pipeline

Figure 2.8. Tasks performed in stages of build pipeline

Figure 2.9. Updating variable settings on Windows

Figure 2.10. Task dependency graph

Chapter 3. Building a Gradle project by example

Figure 3.1. The To Do application is accessible through the internet and manages action items in a data store.

Figure 3.2. Web-based user interface of To Do application and its actions

Figure 3.3. Listing all available tasks represented as a sequence diagram

Figure 3.4. Java EE provides components for building a web application based on the MVC architecture pattern.

Figure 3.5. Finding all to-do items use case: the user issues an HTTP request through the browser, which is served by a Servlet and renders the result through a JSP.

Figure 3.6. Set up the wrapper in two easy steps: add the wrapper task and execute it.

Figure 3.7. When a wrapped task is executed, the Gradle runtime is downloaded, unpacked, and used.

Chapter 4. Build script essentials

Figure 4.1. Two basic concepts of a Gradle build are projects and tasks. A project can depend on other projects in the context of a multiproject build. Similarly, tasks can form a dependency graph that guarantees their execution order.

Figure 4.2. Main entry point of a Gradle build—the Project interface

Figure 4.3. Task interface in Gradle’s API. Tasks can define dependencies on other tasks, a sequence of actions, and conditional execution.

Figure 4.4. The project version is read from a properties file during runtime of the build script. The ProjectVersion data class is instantiated. Each of the version classifiers is translated into a field value of the data class. The instance of ProjectVersion is assigned to the version property of the project.

Figure 4.5. Order of build phases in Gradle’s build lifecycle

Figure 4.6. Gradle determines if a task needs to be executed though its inputs/outputs.

Figure 4.7. The class DefaultTask defines task inputs and outputs.

Figure 4.8. Task dependencies for releasing the project

Figure 4.9. Inheritance hierarchy for the task types Zip and Copy

Figure 4.10. Simple tasks can be directly added by calling methods of your project instance. Task rules can only be added through the task container, so you’ll need to get a reference to it first by invoking the getTasks() method.

Figure 4.11. Examples of build lifecycle hooks

Figure 4.12. Task dependencies represented as Directed Acyclic Graph

Figure 4.13. TaskExecutionGraph provides the method whenReady that’s called when the task graph has been populated.

Figure 4.14. Ways to register a TaskExecutionGraphListener. A listener can be registered through the generic addListener method or through a specific method that only takes an instance of a specialized listener type.

Figure 4.15. Build announcement sent by Growl on Mac OS X

Chapter 5. Dependency management

Figure 5.1. Dependency graph of Hibernate core library

Figure 5.2. Anatomy of automated dependency management

Figure 5.3. Bad metadata complicates the use of transitive dependencies. Dependency metadata in Maven repositories is represented by a project object model (POM) file. If the library developer provides incorrect metadata, the consumer will inherit the problems.

Figure 5.4. Declaring a dependency on the Cargo libraries in a Gradle build

Figure 5.5. Configurations can be added and accessed through the Project instance

Figure 5.6. Different types of dependencies can be added on the project level.

Figure 5.7. Dependency attributes in shortcut notation

Figure 5.8. Relevant interfaces in Gradle’s API for configuring various types of repositories. Gradle supports repository implementations for flat directories, Maven, and Ivy.

Figure 5.9. How a dependency declaration maps to artifacts in a Maven repository

Figure 5.10. View of dependency graph with different report types

Chapter 6. Multiproject builds

Figure 6.1. Spring’s modularized architecture

Figure 6.2. Proposed modules for the To Do application

Figure 6.3. Hierarchical multiproject structure for To Do application, which defines three subprojects

Figure 6.4. Settings API representation. You can use the Settings instance to retrieve the project descriptor or project instance through the interface Gradle.

Figure 6.5. The settings file is evaluated and executed during the initialization phase.

Figure 6.6. Settings file resolution is a two-step process.

Figure 6.7. Comparison of hierarchical and flat project layouts and their settings file configurations

Figure 6.8. Important methods of the Project API for implementing multiproject builds

Figure 6.9. Multiproject task execution order when running the task build from the root project

Figure 6.10. Defining common project behavior with the Project API

Chapter 7. Testing with Gradle

Figure 7.1. Test automation pyramid

Figure 7.2. Standard test source and output directories

Figure 7.3. Test configuration inheritance hierarchy

Figure 7.4. Test tasks seamlessly integrate into the build lifecycle.

Figure 7.5. Successful JUnit HTML test report

Figure 7.6. Additional test tasks integrated into build lifecycle

Figure 7.7. Test report aggregation within build lifecycle

Figure 7.8. Aggregated HTML test report

Figure 7.9. Relevant Test API classes

Figure 7.10. Test execution with two forked processes at a time

Figure 7.11. Registering test lifecycle hooks

Figure 7.12. Starting, preparing, and stopping the database for integration testing

Figure 7.13. Scripted page workflow

Figure 7.14. Configurations introduced for assigning functional test dependencies

Figure 7.15. Browser test automation tasks

Chapter 8. Extending Gradle

Figure 8.1. Managing CloudBees runtime services through HTTP from a Gradle build script

Figure 8.2. Signing up for a CloudBees account

Figure 8.3. CloudBees Grand Central landing page

Figure 8.4. Provisioning the To Do application on RUN@cloud

Figure 8.5. Implementing the CloudBees plugin in three steps

Figure 8.6. Version 0.1 of the To Do application deployed to CloudBees

Figure 8.7. Custom task implementation options

Figure 8.8. Plugin architecture

Figure 8.9. Java plugin features

Figure 8.10. Implementation options for object plugins

Chapter 9. Integration and migration

Figure 9.1. Access to Ant functionality from Gradle is provided through the class AntBuilder

Figure 9.2. Importing an existing Ant script into Gra

Figure 9.3. Using Ant tasks from Gradle

Figure 9.4. Relevant Ant task elements in Gradle

Figure 9.5. Wrapping an imported Ant target by exposing a Gradle task with a new name

Figure 9.6. Generating Gradle build scripts from a Maven POM

Figure 9.7. Comparing build outcomes of two different Gradle versions

Figure 9.8. Sample build comparison HTML report for upgrading a Gradle version

Chapter 10. IDE support and tooling

Figure 10.1. IDE project generation with Gradle

Figure 10.2. Eclipse project files

Figure 10.3. Imported projects in Eclipse

Figure 10.4. IntelliJ IDEA project files

Figure 10.5. Imported projects in IntelliJ IDEA

Figure 10.6. Sublime Text project files

Figure 10.7. Imported projects in Sublime Text

Figure 10.8. Built-in Gradle support in IDEs

Figure 10.9. Installing the Groovy and Gradle plugins from the dashboard

Figure 10.10. Gradle project import wizard

Figure 10.11. Importing a multiproject Gradle build

Figure 10.12. Imported Gradle project in use in STS

Figure 10.13. Selecting the Gradle build script to import

Figure 10.14. Gradle runtime configuration

Figure 10.15. Setting project details

Figure 10.16. Imported Gradle project in use in IntelliJ

Figure 10.17. Adding the downloaded Gradle plugin

Figure 10.18. Installing the Gradle plugin

Figure 10.19. Importing the Gradle project

Figure 10.20. Imported Gradle project in use in NetBeans IDE

Chapter 11. Building polyglot projects

Figure 11.1. Invoking the Grunt executable from Gradle

Figure 11.2. Java plugin automatically applies the Java base plugin

Figure 11.3. Groovy plugin inherits capabilities from the Java base plugin

Figure 11.4. Default source directories for projects applying the Groovy plugin

Figure 11.5. Scala plugin inherits capabilities from the Java base plugin

Figure 11.6. Default source directories for projects applying the Scala plugin

Chapter 12. Code quality management and monitoring

Figure 12.1. Code analysis phase in the context of the deployment pipeline

Figure 12.2. Code analysis tasks in relation to the standard Java plugin tasks

Figure 12.3. Sample JaCoCo HTML report

Figure 12.4. Sample Cobertura HTML report

Figure 12.5. Sample Checkstyle HTML report

Figure 12.6. Sample PMD HTML report

Figure 12.7. Sample FindBugs HTML report

Figure 12.8. Sample JDepend HTML report

Figure 12.9. Gradle’s interaction with Sonar

Figure 12.10. Central Sonar dashboard

Figure 12.11. Sonar project dashboard

Figure 12.12. Unit test coverage widget in Sonar

Figure 12.13. Populated unit and integration test code coverage widgets in Sonar

Chapter 13. Continuous integration

Figure 13.1. Anatomy of a CI environment

Figure 13.2. Signing up for a free GitHub account

Figure 13.3. Forking the sample repository

Figure 13.4. Jenkin’s Plugin Manager page

Figure 13.5. Installing the Git plugin

Figure 13.6. Installing the Gradle plugin

Figure 13.7. Restarting Jenkins through the browser

Figure 13.8. Creating the free-style build job

Figure 13.9. Configuring the Git repository

Figure 13.10. Polling the repository for changes minute by minute

Figure 13.11. Configuring the Gradle build invocation

Figure 13.12. Setting up a post-build email notification action

Figure 13.13. Build executing in progress

Figure 13.14. Build job executed successfully

Figure 13.15. Job execution console output

Figure 13.16. Configuring test reporting for all subprojects

Figure 13.17. Test result trend graph

Figure 13.18. Configuring code coverage reporting

Figure 13.19. Code coverage trend graph

Figure 13.20. Modeling the first phases of a build pipeline

Figure 13.21. Passing a parameter from one build job to another when triggered

Figure 13.22. Build name expression for initial job

Figure 13.23. Archiving the initial job workspace

Figure 13.24. Cloning the archived workspace in subsequent jobs

Figure 13.25. Creating a new build pipeline view

Figure 13.26. Build pipeline view

Chapter 14. Artifact assembly and publishing

Figure 14.1. Tasks for creating additional artifact

Figure 14.2. Publishing artifacts to local and remote repositories

Figure 14.3. Publishing artifacts to a Maven repository

Figure 14.4. Uploaded artifacts in Artifactory repository browser

Figure 14.5. Publishing artifacts to Bintray

Figure 14.6. Uploaded artifacts in Bintray dashboard

Figure 14.7. Publishing artifacts to Sonatype OSS

Figure 14.8. Creating the distribution in the context of the build pipeline

Figure 14.9. Publishing a WAR file to Artifactory with different versions

Figure 14.10. Retrieving a WAR file from Artifactory for deployment purposes

Figure 14.11. Applying Maven’s standard versioning scheme in a build pipeline

Figure 14.12. Setting a dynamic, incrementing version number at the initial phase of the build pipeline

Figure 14.13. Versioning scheme for To Do application

Figure 14.14. Build pipeline view

Chapter 15. Infrastructure provisioning and deployment

Figure 15.1. Creating test environments with Vagrant and Puppet

Figure 15.2. Software propagation through different environments

Figure 15.3. Reading Groovy script during Gradle’s configuration phase

Figure 15.4. Targeting specific environments by providing a project property

Figure 15.5. Running smoke tests against different environments

Figure 15.6. Acceptance, UAT, and production stages as part of the build pipeline

Figure 15.7. Deploying the WAR file to a test server for acceptance testing

Figure 15.8. Deployment tests against deployed WAR file

Figure 15.9. Performing push-button releases to UAT and production environments