build1.includedBuilds() >> [includedBuild2]
        build1.parent >> rootBuild

        includedBuildState1.mutableModel >> build1

        includedBuildState2.projects >> projects2
        includedBuildState2.buildRootDir >> dir2
        includedBuildState2.importableBuild >> true

        build2.includedBuilds() >> []
        build2.parent >> rootBuild

    /**
     * This method is only here to maintain compatibility with existing builds.
     *
     * @deprecated Use {@link #getDistsDirectory()}. This method is scheduled for removal in Gradle 9.0.
     */
    @Deprecated
    String getDistsDirName();

    /**
     * This method is only here to maintain compatibility with existing builds.
     *

<<getting_started_eng.adoc#introduction,Running Gradle Builds>> :: Learn Gradle basics and how to use Gradle to build your project.
<<build_lifecycle.adoc#build_lifecycle,Authoring Gradle Builds>> :: Develop tasks and plugins to customize your build.
<<building_java_projects.adoc#building_java_projects,Authoring JVM Builds>> :: Use Gradle with your Java project.

import org.gradle.tooling.model.gradle.GradleBuild
import spock.lang.Issue

class GradleBuildModelCrossVersionSpec extends ToolingApiSpecification {

    @TargetGradleVersion(">=3.3")
    def "Included builds are present in the model"() {
        given:
        def rootDir = singleProjectBuildInRootFolder("root") {
            settingsFile << """
                rootProject.name = 'root'

== Using composite builds in a hierarchical multirepo project

This sample demonstrates how composite builds can be used to develop a hierarchical project that is composed from different Git repositories. Instead of Gradle subprojects in a multiproject build, this example uses separate Gradle builds included into a composite.

Composite builds allow you to:

- Extract your build logic from your project build (and re-use it among subprojects)
- Combine builds that are usually developed independently (such as a plugin and an application)
- Decompose a large build into smaller, more isolated chunks

== Step 4. Add build to the Build

Let's add a plugin to our build.
First, create a new directory called `license-plugin` in the `gradle` directory:

1. Clean the cache directory to avoid any hits from previous builds (`rm -rf $GRADLE_USER_HOME/caches/build-cache-*`)
2. Run the build (e.g. `./gradlew --build-cache clean assemble`), so that all the results from cacheable tasks get stored in the cache.
3. Run the build again (e.g. `./gradlew --build-cache clean assemble`); depending on your build, you should see many of the tasks being retrieved from the cache.

Gradle uses two main features to reduce build time: *incremental builds* and *build caching*.

image::gradle-basic-8.png[]

== Incremental builds

An *incremental build* is a build that avoids running tasks whose inputs have not changed since the previous build.
Re-executing such tasks is unnecessary if they would only re-produce the same output.

For incremental builds to work, tasks must define their inputs and outputs.

    def "builds dependency for nonIdea project"() {
        when:
        def dependency = builder.create(projectId, 'compile')

        then:
        dependency.scope == 'compile'
        dependency.name == "project-name"

        and:
        artifactRegistry.getIdeProject(_, _) >> null
    }

    def "builds dependency for nonIdea root project"() {
        when:

/**
 *
 * <p>A {@code TestLauncher} allows you to execute tests in a Gradle build.</p>
 *
 * <p>If the target Gradle version is &gt;=6.8 then you can use {@code TestLauncher} to execute tests from included builds. Test operation descriptors from included builds work out-of-the-box. You can
 * target tasks from included builds by specifying the task identity path (i.e. {@code ':included-build-name:subproject-name:taskName'}).</p>
 *