Be aware these are very technical descriptions of the decisions, and you might find the documentation below more useful as an introduction to the internals of Gradle.

## Platform architecture

Gradle is arranged into several coarse-grained components called "platforms".
Each platform provides support for some kind of automation, such as building JVM software or building Gradle plugins.
Most platforms typically build on the features of other platforms.

The build state also includes what is currently called the "Gradle state". The Gradle state is being merged into the build state and is mostly empty.

### Project state

The "project state" holds the state for a project for a single build execution, and is contained by the build state (and not the state of the parent project).

<!-- 
  -- Note: this file contains a generated diagram. Use `./gradlew :architectureDoc` to generate 
  -->

# Gradle platform architecture

Gradle is arranged into coarse-grained components called "architecture modules" and "platforms".
See [ADR4](standards/0004-use-a-platform-architecture.md) for a definition of these terms.

The diagram below shows the current set of architecture modules and platforms:

- CLI client. This is the `gradle` or `gradlew` command, and is responsible for locating, starting and interacting with the Gradle daemon, potentially downloading the Gradle distribution. 
- Tooling API client. This a library that is embedded into applications, such as IDEs or CI agents, that allows them to act as a Gradle client.
- Worker processes. Long-running daemon processes that the Gradle daemon starts to run specific kinds of work, such as compilation or test execution.