## 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.

      with:
        # Action runs a custom dependencies task that fails with config-cache on Gradle 8.7 (works with 8.6)
        additional-arguments: --no-configuration-cache
      env:
        # Exclude some projects and configurations that should not contribute to the dependency graph
        DEPENDENCY_GRAPH_EXCLUDE_PROJECTS: ':docs|:internal-performance-testing|:enterprise-plugin-performance|:performance|:internal-integ-testing'

* Be careful when using features introduced in Java 1.7 or later. Some parts of Gradle still need to run on Java 6.
* Normalize file paths in tests. The `org.gradle.util.internal.TextUtil` class has some useful functions for this purpose.

You can consult the [Architecture documentation](architecture) to learn about some of the architecture of Gradle.

### JVM platform

This is a platform that builds on the core and software platforms to add support for developing software that runs on the JVM.
This includes software that is implemented using Java, Kotlin or some other JVM language.

This platform provides specific support for Java, Groovy and Scala, and includes the foojay toolchain plugin.

### Extensibility platform

        if: ${{ failure() }}
        uses: actions/github-script@v7
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const output = `
            Some bad merge is found:
            \`\`\`
            ${{ env.OUTPUT }}
            \`\`\`
            `;
            github.rest.issues.createComment({
              issue_number: context.issue.number,

            listOf(
                "KILL_LEAKED_PROCESSES_FROM_PREVIOUS_BUILDS",
                "GRADLE_RUNNER",
                "KILL_PROCESSES_STARTED_BY_GRADLE",
                "CHECK_CLEAN_M2_ANDROID_USER_HOME"
            ),
            steps.items.map(BuildStep::name)
        )
        assertEquals(expectedRunnerParam(), getGradleStep("GRADLE_RUNNER").gradleParams)
    }

    @ParameterizedTest
    @CsvSource(

    params {
        param("credentialsStorageType", "credentialsJSON")
        // Disallow Web UI changes to TeamCity settings
        param("teamcity.ui.settings.readOnly", "true")
        // Avoid rebuilding same revision if it's already built on another branch
        param("teamcity.vcsTrigger.runBuildOnSameRevisionInEveryBranch", "false")

The build process state also includes state that is tied to a particular Gradle user home directory.
When that directory changes between Gradle invocations, the state is discarded and recreated.
Typically, the Gradle user home directory does not change for a given process, so this is effectively process state.

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.

            // https://blog.jetbrains.com/teamcity/2013/05/explaining-the-shared-resources-plugin/
            // we only allow 1 promotion job running at the same time to avoid website xml conflicts
            feature {
                type = "JetBrains.SharedResources"
                param("locks-param", "WebsiteReleasesXml writeLock")
            }
        }
    }