withDefaultSettings().appendText(
            """
                include("producer", "consumer")
            """
        )
        withKotlinDslPlugin().appendText(
            """
                subprojects {
                    apply(plugin = "org.gradle.kotlin.kotlin-dsl")
                    $repositoriesBlock
                }
                project(":consumer") {
                    dependencies {

3. You added a subproject and a separate Build in <<partr3_multi_project_builds#part3_begin, part3>>.
4. You viewed a Settings file in <<partr4_settings_file.adoc#part4_begin,part 4>>.

== Step 1. The `Project` object

Build scripts invoke Gradle APIs to configure the build.

During the configuration phase, Gradle finds the build script(s) in the root and subproject directories.

        "nope"   | _
        "y"      | _
        "n"      | _
    }

    @ToBeFixedForIsolatedProjects(because = "subprojects")
    def "can ask yes/no question when build is executed in parallel"() {
        given:
        withParallel()

        buildFile << """
            subprojects {
                task "askYesNo"
            }
        """
        createDirs("a", "b", "c")

            public class Leaking {
            }
        """

        expect:
        succeeds 'compileTestJava'
    }

    def "can consume test fixtures of subproject"() {
        settingsFile << """
            include 'sub'
        """
        file("sub/build.gradle") << """
            apply plugin: 'java-test-fixtures'
        """
        buildFile << """

====

If adding such a file to your jar files is something you do for all of the projects in your build, and you want to filter this file for all consumers, you may wrap the configurations described above in an `allprojects {}` or `subprojects {}` block in the root build script.

The effect of this configuration would be that changes to `build-info.properties` would be ignored for both up-to-date checks and task output caching.

        expect:
        succeeds("verifyConfigurations")
    }

    private void packagingTasks(boolean expectExecuted, String subproject, String feature = '') {
        def tasks = [":$subproject:process${feature.capitalize()}Resources", ":$subproject:${feature.isEmpty() ? 'classes' : feature + 'Classes'}", ":$subproject:${feature.isEmpty() ? 'jar' : feature + 'Jar'}"]
        if (expectExecuted) {
            executed(*tasks)
        } else {

    }

    def multiProjectBuild(String projectName, List<String> subprojects, @DelegatesTo(value = BuildTestFile, strategy = Closure.DELEGATE_FIRST) Closure cl = {}) {
        multiProjectBuild(projectName, subprojects, CompiledLanguage.JAVA, cl)
    }

        createDirs("child1", "child2")
        settingsFile << "include 'child1', 'child2'"
        buildFile << """
            defaultTasks 'a', 'b'
            task a
            subprojects {
                task a(dependsOn: ':a')
                task b(dependsOn: ':a')
            }
        """

        expect:
        2.times {

== Step 1. Understanding the Version Catalog
A version catalog is used to declare all direct dependencies of a project in a central location.

It is created in by Gradle init in `gradle/libs.versions.toml` and referenced in subproject build files.

.libs.versions.toml
[source,text]
----
[versions]
guava = "32.1.2-jre"
junit-jupiter = "5.10.0"

[libraries]
guava = { module = "com.google.guava:guava", version.ref = "guava" }

[.multi-language-sample]
=====
[source,kotlin]
----
.
├── a-subproject
│   └── build.gradle.kts
├── settings.gradle.kts
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
└── gradlew.bat
----
=====
[.multi-language-sample]
=====
[source,groovy]
----
.
├── a-subproject
│   └── build.gradle
├── settings.gradle
├── gradle