## Build state model

As Gradle executes, it acts on various pieces of the build definition, such as each project in the build.
Gradle tracks the state of each piece and transitions each piece through its lifecycle as the build runs.

A central part of the Gradle architecture is the "build state model", which holds the state for each piece and coordinates state transitions and other mutations. 

The project state is managed by the `ProjectState` class.
It is created for each project in the build definition, once per build execution and is discarded at the end of the execution.

## Composition by architecture modules

Each [architecture module and platform](platforms.md) can contribute code to any of the elements.
Not every module contributes to every element.

manifest:
  version: 1.0

# The `automations` section lists automations to run on PRs in this repository.
# Each automation has an `if` key that defines conditions to run the automation,
# as well as a `run` key with the actions to do. All the conditions need to be true
# for the actions to run (there is an implicit AND relation between
# the conditions on each line).  Each condition is specified as a Jinja expression.  You

## Structure

Each platform and module has its own source directory under [platforms/](../platforms).
In these source directories, you will find the Gradle projects that make up the platform or module.

The platforms and modules are defined using a DSL in [settings.gradle.kts](../settings.gradle.kts)

        /**
         * Run at the beginning of each build. Kill potentially leaked processes in previous builds.
         * Only kill local Gradle processes (classpath in checkout directory).
         * Not clean up global Gradle processes (i.e. classpath in ~/.gradle/...).
         */
        KILL_LEAKED_PROCESSES_FROM_PREVIOUS_BUILDS,
        /**
         * Run at the end of each build. Kill potentially leaked processes in the current build.

### Contributing to documentation

This repository includes Gradle documentation sources,
including but not limited to: User Manual, DSL Reference and Javadoc.
This information is used to generate documentation for each Gradle version
on [docs.gradle.org](https://docs.gradle.org/).
The documentation is mostly implemented in Asciidoc
though we use GitHub-flavored Markdown for internal documentation too.

    
```

These are all Java processes. Each process has a corresponding "runtime".
All source code in Gradle is written to target one or more of these runtimes.
Most source code targets the daemon and the remaining code either targets a single runtime, for example the Gradle client, or is shared across multiple runtimes.

## Composition by architecture modules