## Architecture decision records (ADRs)

The Gradle team uses ADRs to record architectural decisions that the team has made.

See [Architecture decisions records](standards) for the list of ADRs.
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

    implementation("org.gradle.guides:gradle-guides-plugin")
    implementation("org.asciidoctor:asciidoctor-gradle-jvm") {
        because("This is a transitive dependency of 'gradle-guides-plugin' not declared there")
    }

# 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
# can also use the constant `true` if you want to always run the actions.

    }

    public static List<String> getDefaultExcludedPackages() {
        // TODO: This should be configured via the extension vs hardcoded in the plugin
        List<String> excludedPackages = new ArrayList<>();
        // These are part of the API, but not the DSL
        excludedPackages.add("org.gradle.tooling.**");
        excludedPackages.add("org.gradle.testfixtures.**");

                    enabled = branch.enableVcsTriggers
                    // https://www.jetbrains.com/help/teamcity/2022.04/configuring-schedule-triggers.html#general-syntax-1
                    // We want it to be triggered only when there're pending changes in the specific vcs root, i.e. GradleMaster/GradleRelease
                    triggerRules = "+:root=${VersionedSettingsBranch.fromDslContext().vcsRootId()}:."

## Project structure

Mostly a standard Maven project structure. The entry point `settings.kts` defines the TeamCity project.

There are 3 subprojects in the TeamCity project hierarchy: `Check` for Gradle builds, `Promotion` for releasing Gradle versions, `Util` for miscellaneous utilities.

## Develop and verify

import org.gradle.api.provider.Property
import java.io.File


/**
 * An extension to work with {@see TestFilesCleanupService}.
 * We have to collect all information we need in this extension and pass them
 * to the build service.
 */
interface TestFilesCleanupBuildServiceRootExtension {
    val projectStates: MapProperty<String, TestFilesCleanupProjectState>

    /**

 * modules that are not loaded transitively by other project modules.
 *
 * We perform this filtering, since if we simply include all external dependencies, regardless of whether
 * they are already loaded transitively, there is a measurable performance impact during module-loading.
 */
fun computeExternalDependenciesNotAccessibleFromProjectDependencies(
    rootComponent: ResolvedComponentResult,
    rootVariant: ResolvedVariantResult

import static com.google.common.collect.Iterables.getOnlyElement;
import static java.util.stream.Collectors.toList;

/**
 * Extracts Kotlin DSL runtime generated sources.
 *
 * Current implementation extracts these from the wrapper's API jars.
 * This is not correct as it should do this with the built distribution instead.
 *
 * Doing it correctly would require running a Gradle build with the full

# 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
# can also use the constant `true` if you want to always run the actions.