given: "a plugin that creates a custom extension using a DependencyCollector"
        file("build-logic/src/main/java/com/example/restricted/DependenciesExtension.java") << defineDependenciesExtension()
        file("build-logic/src/main/java/com/example/restricted/LibraryExtension.java") << defineLibraryExtension()

== Share logic in `buildSrc`

`buildSrc` is a Gradle-recognized and protected directory which comes with some benefits:

1. *Reusable Build Logic*:
+
`buildSrc` allows you to organize and centralize your custom build logic, tasks, and plugins in a structured manner.
The code written in buildSrc can be reused across your project, making it easier to maintain and share common build functionality.

2. *Isolation from the Main Build*:
+

Let's take the previous example.
The logic in `buildSrc` has been turned into a project that contains plugins and can be published and worked on independently of the root project build.

The plugin is moved to its own build called `build-logic` with a build script and settings file:

No sub-projects
"""
    }

    def "project project structure and software types for multi-project build using declarative dcl"() {
        given: "a build-logic build registering an ecosystem plugin defining several software types via several plugins"
        file("build-logic/src/main/java/com/example/restricted/LibraryExtension.java") << """
            package com.example.restricted;

            import org.gradle.api.provider.Property;

        outputContains("Execution: build-logic-value")

        when:
        System.clearProperty("someProperty")
        configurationCacheRun "print", "-DsomeProperty=cli-overridden-value"

        then:
        configurationCache.assertStateLoaded()
        outputContains("Execution: build-logic-value")
    }

    def "reports build logic reading files in #title"() {

│   │   └──...
│   └── build.gradle.kts
└── settings.gradle.kts
----

The build file of the `database-logic` subproject is as follows:

====
include::sample[dir="snippets/plugins/pluginProject/kotlin",files="database-logic/build.gradle.kts[]"]
include::sample[dir="snippets/plugins/pluginProject/groovy",files="database-logic/build.gradle[]"]
====

                    }
                }
            }
        """

        file(extensionFile) << extensionCode

        file("build-logic/src/main/java/com/example/restricted/SoftwareTypeRegistrationPlugin.java") << defineSettingsPluginRegisteringSoftwareTypeProvidingPlugin()
        file("build-logic/src/main/java/com/example/restricted/RestrictedPlugin.java") << """
            package com.example.restricted;

├── settings.gradle
├── subproject-one
│   └── build.gradle
└── subproject-two
    └── build.gradle
----
=====
====

[[sec:build_sources]]
== Use `buildSrc` to abstract imperative logic

Complex build logic is usually a good candidate for being encapsulated either as custom task or binary plugin.
Custom task and plugin implementations should not live in the build script.

}

dependencies {
    implementation(project(':some-logic'))  // dependency on some-logic
}
----
=====
====

If we run `:app:build` again, we see the Java code of `some-logic` is also compiled by Gradle automatically:

[source,text]
----
$./gradlew :app:build

> Task :app:processResources NO-SOURCE
> Task :app:processTestResources NO-SOURCE

// limitations under the License.

[[test_kit]]
= Testing Build Logic with TestKit