Building and Testing with Gradle

Chapter 6. Multiproject Builds

Large projects are typically broken up into separate modules with independent build lifecycles. Each subproject has some kind of life of its own, perhaps with a development team assigned to it alone, and certainly with a test suite of its own which is worthwhile to run apart from the project as a whole. However, any large system that is broken into pieces must also be reintegrated together, implying the need for a master build that combines all subprojects into a single integration test suite and set of release artifacts or processes. A next-generation build system will be equipped to provide a flexible framework for dealing with real-world project differentiation and integration.

Multiproject Build Structure

A multiproject is generally hierarchical in nature: it typically has a master project with one or more subprojects. In some cases, subprojects may be nested. The master project goes in a top-level directory, with subprojects arranged in subdirectories underneath. The master project may add code, resources, tests, and build conventions of its own, or it may simply be build glue that holds the project tree together.

In the most intuitive case, Gradle allows you to define a build file for the top-level project and one for each subproject. In a more interesting and potentially more useful case, it also lets you define the entire build from the top-level build file. Alternatively, if neither a scattered set of individual build files nor a single, integrated ...