Important
This project shows how to use Gradle in a structured way not only for simple, but also rather complex project setups. In this context, it is rather "academic" and contains quite some "Gradle boilerplate". If you want to understand Gradle on a deeper level, it is a great resource. And if you are looking for more explanation on the different features used here, you can finde that in my 👉 Understanding Gradle video series.
If you are looking for a (more or less) standard setup for a project, I would recommend looking at my other repository 👉 Gradle Project Setup HowTo first or instead.
There is also 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:
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.
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
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.
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
assembleorcheck) - 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
- ...
- Alternative setups to use or not use Gradle's Version Catalog concept (see #4).
- Do not use the Catalog - Removes the
libs.versions.tomlcatalog and instead uses GA coordinates directly (versions are managed in platform project) - Use only the Catalog (remove Platform) - Remove the
gradle/platformproject and put the versions directly into the catalog instead.
- Do not use the Catalog - Removes the
- Using or not using a Version Catalog
- How to use an external plugin in a local plugin and where to put its version
- Name of 'Settings Plugin' project
- Using JVM packages for precompiled script plugins
- Where to put the Gradle Wrapper
More questions or points you would like to discuss? Please open an issue.
More questions or points you would like to discuss? Please open an issue.