Example of how to idiomatically structure a large build with Gradle 7.2+
For a better understanding of the concepts used in this example, check out Understanding Gradle.
Example
There is now documentation and another sample on this topic in the Gradle User Manual.
This example is a software product called Idiomatic Gradle (IG).
To build the example, clone this repository and run the following for more information:
./gradlew :tasks
./gradlew :projects
This example consists of:
Production code
Inside the 'product' folder, there are three components/builds:
product/ig-server
: A server providing some servicesproduct/ig-api
: A client API Jar that clients (e.g. Android Apps) can integrate directlyproduct/ig-common
: Some common code used by both Server and API Jar
For the sake of the sample each of these folders only contain one subproject. In a real-world application, this can be structured into many, many more Gradle subprojects.
Packaging and Publishing
Both the server and the client API Jar require some special packaging to be published/distributed. Hence, this is configured in a separate component/build only responsible for aggregating build results:
aggregation/package-server
: Package the complete server and its dependencies into one fat jar that can run without other dependenciesaggregation/publish-api
: Package the client into one Jar that is published to a Maven repository
Testing
Each project contains unit tests using Gradle's default setup for Java projects with the src/test/java
folder.
Furthermore, some projects contain end2end tests testing with the real (packaged) server and the real client API Jar.
For this, the packaging/publishing projects provide their results in the build for other subprojects to consume.
Idiomatic Build Logic Structure
The build contains some standard configuration for Java compilation and testing. It contains more involved configuration code to configure the packaging/publishing and the end2end test setup. There are multiple ways to do all this in Gradle today. This sample employs the following good patterns which result in a good build structure (easy to maintain and fast for Gradle to execute) as described here.
With this, the following outdated practices are avoided:
- No direct dependencies between tasks declared (except for extending lifecycle tasks like
assemble
orcheck
) - No direct dependencies between tasks from different subprojects are declared
- No cross-project configuration (subproject / allprojects) is performed
- Each build script of a subproject is simpler to read as all relationships to other projects are expressed in terms of dependencies
- ...