* To provide best practices and solutions we (as the *build tool* team) want to promote.
* To avoid asking the same thing multiple times during code review.
* To explain *rejected solutions*, for now, and future development, in case they are proposed again.

ADRs can be written by any team.
Like code, they should be reviewed by any other relevant teams.

* work on the Gradle code base
* get help if you encounter trouble

## Before you start

Before starting to work on a feature or a bug fix, please open an issue to discuss the use case or bug with us. This can save everyone a lot of time and frustration.

For any non-trivial change, we need to be able to answer these questions:

* Why is this change done? What's the use case?

platforms/core-execution/                                   @gradle/bt-execution
platforms/core-execution/build-cache/                       @gradle/bt-execution @gradle/bt-dv-build-cache
platforms/core-execution/build-cache-base/                  @gradle/bt-execution @gradle/bt-dv-build-cache
platforms/core-execution/build-cache-http/                  @gradle/bt-execution @gradle/bt-dv-build-cache

import java.util.jar.Attributes

plugins {
    id("gradlebuild.module-identity")
}

val moduleIdentity = the<ModuleIdentityExtension>()

configureJarTasks()

pluginManager.withPlugin("java-base") {
    configureClasspathManifestGeneration()
}

fun configureJarTasks() {
    tasks.withType<Jar>().configureEach {
        archiveBaseName = moduleIdentity.baseName

It is made up of 3 architecture modules:

- **core-runtime**: Provides the runtimes or "containers" in which code runs. These runtimes include the Gradle client, the daemon and the worker processes. This is the base module on which all other architecture modules depend.
- **core-configuration**: Allows the build structure and work, such as tasks, to be specified. This includes the project model, the DSL and so on.

Not every module contributes to every runtime.

The core-runtime module defines each runtime:

- The target JVM for the runtime. Each runtime has its own JVM compatibility constraints.
- Some base services that are available to code hosted by the runtime. This varies by runtime.
- Additional constraints. For example, the CLI client runtimes limit the libraries that are available to the code in that runtime, for performance reasons. 

            against THE LATEST VERSION WHICH IS RELEASED FROM RELEASE BRANCH (from `released-version.json` on this branch)
            AND LOWER THAN CURRENT BASE VERSION (from `version.txt` on this branch).
            The difference must identically match <a href="${apiChangesJsonFile.asFile.path}">accepted-public-api-changes.json</a>, no more, no less - otherwise the task will fail.