buildTestFixture.singleProjectBuild(projectName, cl)
    }

    def multiProjectBuild(String projectName, List<String> subprojects, @DelegatesTo(BuildTestFile) Closure cl = {}) {
        buildTestFixture.multiProjectBuild(projectName, subprojects, cl)
    }

    List<TestFile> sourceFiles
    VerboseVfsLogAccessor vfsLogs

    def setup() {
        buildTestFixture.withBuildInSubDir()
        def subprojects = (1..NUMBER_OF_SUBPROJECTS).collect { "project$it" }
        def rootProject = multiProjectBuild("javaProject", subprojects) {
            buildFile << """
                allprojects {
                    apply plugin: 'java-library'

class ToolingApiIdeaModelCrossVersionSpec extends ToolingApiSpecification implements WithOldConfigurationsSupport {
    def "Provides target module name for module dependencies"() {


        file('build.gradle').text = """
subprojects {
    apply plugin: 'java'
}

project(':impl') {
    apply plugin: 'idea'

    dependencies {
        ${implementationConfiguration} project(':api')
    }
}
"""

====
include::sample[dir="snippets/plugins/multiproject/kotlin", files="settings.gradle.kts[tags=include-subprojects];build.gradle.kts[tags=plugins-on-subprojects];hello-a/build.gradle.kts[];hello-b/build.gradle.kts[];goodbye-c/build.gradle.kts[]"]

<3> Gradle wrapper start scripts
<4> Settings file to define build name and subprojects
<5> Build script for `app` subproject
<6> Default Java source folder for `app` subproject
<7> Default Java test source folder for `app` subproject
=====

The `authoring-tutorial` folder is the *root project directory*.
Inside the root project directory are one or more subprojects, build scripts, and the Gradle wrapper.

plugins {
    id 'java-platform'
}

// tag::define-platform[]
dependencies {
    constraints {
        // Platform declares some versions of libraries used in subprojects
        api 'commons-httpclient:commons-httpclient:3.1'
        api 'org.apache.commons:commons-lang3:3.8.1'
    }
}

        then:
        content.contains('Please <a href="https://github.com/gradle/guides/issues/new?labels=in:creating-build-scans">add an issue</a> or pull request to <a href="https://github.com/gradle/guides/tree/master/subprojects/creating-build-scans">gradle/guides</a>')
    }

    def "can use guide-name attribute on document to customize the issue and repository urls"() {
        given:
        String asciidocContent = """

        """

        buildFile """
            println("lifecycle: <evaluating> '\${project.path}'")
            subprojects { println("lifecycle: <root>.subprojects '\${it.path}'") }
        """

        groovyFile "a/build.gradle", """
            println("lifecycle: <evaluating> " + project)
        """

        when:
        succeeds("help")

If your build includes multiple subprojects, create tasks to build those subprojects
independently. This helps you get the most out of caching, since a change to one
subproject won't force a rebuild for unrelated subprojects. And this helps reduce
build times for teams that work on unrelated subprojects: there's no need for
front-end developers to build the back-end subprojects every time they change the

This sample shows how build logic in a multi-project build can be organized into reusable plugins.

== Use case

As an example, let's say a project with three subprojects produces two public Java libraries that use the third subproject as an internal shared library.
This is the project structure:

====
[.multi-language-sample]
=====
.Project structure
[source, kotlin]
----
├── internal-module