@IntegrationTestTimeout(value = 60, onlyIf = { GradleContextualExecuter.embedded })
    def "can query dependencies with configure on demand enabled"() {
        def subprojects = ["a", "b"]
        multiProjectBuild("outputRegistry", subprojects)
        subprojects.each { projectName ->
            file("${projectName}/build.gradle") << """
                plugins {
                    id("java-library")
                }

<4> Settings file to define build name and subprojects
<5> Build script of _buildSrc_ to configure dependencies of the build logic
<6> Source folder for _convention plugins_ written in Groovy or Kotlin DSL
<7> Build script of the three subprojects - `app`, `list` and `utilities`
<8> ${language.raw} source folders in each of the subprojects
<9> ${language.raw} test source folders in the subprojects

        subproject("base-asm")
        subproject("base-services")
        subproject("build-configuration")
        subproject("build-operations")
        subproject("build-option")
        subproject("build-process-services")
        subproject("build-profile")
        subproject("build-state")
        subproject("cli")
        subproject("client-services")
        subproject("concurrent")
        subproject("daemon-main")

BUILD SUCCESSFUL in 1s
16 actionable tasks: 5 executed, 11 up-to-date
----

So far, we have looked at tasks in individual subprojects, which is useful for local development when you work on code in one subproject.

With this setup, developers only need to know that they can call Gradle with `:subproject-name:tasks` to see which tasks are available and useful for them.

[[sec:global_lifecycle_tasks]]
== Global lifecycle tasks

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

====
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[]"]

        }

        override fun subprojects(action: Action<in Project>) {
            delegate.subprojects(referrer, action)
        }

        override fun subprojects(configureClosure: Closure<*>) {
            delegate.subprojects(referrer, ConfigureUtil.configureUsing(configureClosure))
        }

        override fun subprojects(referrer: ProjectInternal, configureAction: Action<in Project>) {

    }

    // TODO: This could be made more generic by passing a list of subproject names
    // that includes 'googleTest'.
    void generateSettings() {
        project.copy {
            from(new File(projectTemplate, "settings.gradle"))
            into(destDir)
            expand([
                rootProjectName: name,
                subprojects: subprojectNames
            ])
        }
    }

     * If you update the project names then make sure you run gradle eclipse from the root, e.g. for all subprojects.
     * The reason is that there may be subprojects that depend on the subproject with amended eclipse project name.
     * So you want them to be generated as well because the project dependencies in .classpath need to refer to the amended project name.
     * Basically, for non-trivial projects it is recommended to always run gradle eclipse from the root.

<7> The project's <<settings_file_basics.adoc#sec:settings_file_script, settings file>> where the list of subprojects is defined.
<8> Usually, a project is organized into one or multiple subprojects.
<9> Each subproject has its own Gradle build script.

[[dir:project_root:cache_cleanup]]
=== Project cache cleanup