}
            }
        """
    }

    @TargetGradleVersion(">=8.1")
    def "nested actions that query a project model which leverages toolchain information do not cause Property evaluation to be in unexpected state"() {
        given:
        setupBuildWithToolchainsResolution()

        when:
        withConnection {

     *
     * <p>This emulates the normal variant selection process where graph variants are first
     * considered, then artifact variants. We first consider graph variants, which leverages the
     * same algorithm used during graph variant selection. This considers requested and declared
     * capabilities.</p>
     */

import org.eclipse.aether.transfer.TransferResource
import org.gradle.integtests.fixtures.RepoScriptBlockUtil

/**
 * Performs resolution of dependencies against Maven repositories.
 *
 * <p>This resolver leverages Maven's stable public API for dependency resolution and does
 * not run a full Maven build.</p>
 */
class ApiMavenResolver {

    /**
     * The local repository used for caching resolved artifacts.

        when:
        succeeds "resolve"

        then:
        output.count("Minifying") == 1
        output.count('minified=true')
        output.count('Sizing') == 0
    }

    def "disambiguation leverages schema rules before doing it size based"() {
        given:
        createDirs("child")
        settingsFile << """
include('child')
"""
        buildFile << """

* In combination with <<dependency_locking.adoc#dependency-locking,dependency locking>>, you want to publish the locked versions.
* A project leverages the rich versions constraints of Gradle, which have a lossy conversion to Ivy.
Instead of relying on the conversion, it publishes the resolved versions.

* In combination with <<dependency_locking.adoc#dependency-locking,dependency locking>>, you want to publish the locked versions.
* A project leverages the rich versions constraints of Gradle, which have a lossy conversion to Maven.
Instead of relying on the conversion, it publishes the resolved versions.

A first feature using the build cache is _task output caching_.
Essentially, task output caching leverages the same intelligence as <<incremental_build#incremental_build,up-to-date checks>> that Gradle uses to avoid work when a previous local build has already produced a set of task outputs.

.Applying the Kotlin DSL Plugin to a `buildSrc` project
====
include::sample[dir="snippets/kotlinDsl/kotlinDslPlugin/kotlin",files="buildSrc/build.gradle.kts[tags=apply]"]
====

The Kotlin DSL Plugin leverages <<toolchains#toolchains,Java Toolchains>>.
By default the code will target Java 8.
You can change that by defining a Java toolchain to be used by the project:

.Changing the JVM target using toolchains
====

- `getFirstLevelModuleDependencies(Spec)`
- `getFiles(Spec)`
- `getArtifacts(Spec)`

To mitigate this deprecation, consider the example below that leverages the `ArtifactView`
API along with the `componentFilter` method to select a subset of a Configuration's artifacts:

====
[.multi-language-sample]
=====
.build.gradle.kts
[source,kotlin]
----

The Kotlin DSL is embedded into the Gradle Build Tool and, just like the IDE, makes use of the Kotlin toolchain.
Both the Kotlin DSL and the Kotlin toolchain leverage the Gradle Build Cache.

image::images/C4_1_Context.svg[]

## Level 2: Container diagram