def "can use apply block syntax to apply multiple scripts"() {
        given:
        buildScript """
          apply {
            from "script1.gradle"
            from "script2.gradle"
          }
        """

        file("script1.gradle") << "task hello1 { doLast { println 'hello from script1' } }"
        file("script2.gradle") << "task hello2 { doLast { println 'hello from script2' } }"

        when:

    }

    void scriptsAreReused(List<ClassDetails> before, List<ClassDetails> after) {
        assert before.size() == after.size()
        for (int i = 0; i < before.size(); i++) {
            def script1 = before[i]
            def script2 = after[i]
            assert script1.path == script2.path
            assert script1.className == script2.className
            assert script1.classpath == script2.classpath

        result.groupedOutput.task(":two").assertOutputContains("values1=[12]")
    }

    def "problem when closure defined in Kotlin script captures state from the script"() {
        given:
        buildKotlinFile << """
            val message = "message"
            tasks.register("some") {
                doFirst {
                    println(message)

            writer.println("            BasicScript script = precompiledScriptClass.getDeclaredConstructor().newInstance();");
            writer.println("            script.setScriptSource(scriptSource(precompiledScriptClass));");
            writer.println("            script.init(target, target.getServices());");
            writer.println("            script.run();");
            writer.println("        } catch (Exception e) {");

They are applied to a project using the `plugins {}` block.
They provide a way to reuse complex logic across projects and allow for better organization of build logic.

Script Plugins :: Script plugins are Groovy DSL or Kotlin DSL scripts that are applied directly to a Gradle build script using the `apply from:` syntax.

Furthermore, updating the initialization script logic uniformly can prove challenging.

Custom Gradle distributions are a practical solution to this very problem.
A custom Gradle distribution is comprised of the standard Gradle distribution plus one or many custom initialization scripts.
The initialization scripts come bundled with the distribution and are applied every time the build is run.

            .get();
    }

    /**
     * We want to use build cache for script compilation, but build cache might not be available yet with early execution engine.
     * Thus settings and init scripts are not using build cache for now.<br/><br/>
     *
     * When we compile project build scripts, build cache is available, but we need to query execution engine with build cache support

import org.gradle.internal.operations.CallableBuildOperation
import org.gradle.internal.scripts.BuildScriptCompilationAndInstrumentation
import org.gradle.internal.scripts.CompileScriptBuildOperationType.Details
import org.gradle.internal.scripts.CompileScriptBuildOperationType.Result
import org.gradle.internal.scripts.ScriptExecutionListener
import org.gradle.kotlin.dsl.accessors.Stage1BlocksAccessorClassPathGenerator

├── shared
│   ├── src
│   │   └──...
│   └── build.gradle
└── settings.gradle
----
<1> Create the `MyCustomTask` task.
<2> A shared build script.
<3> Uses the `MyCustomTask` task and shared build script.
=====

In the `buildSrc`, the build script `shared.gradle(.kts)` is created.
It contains dependencies and other build information that is common to multiple subprojects:

[.multi-language-sample]
=====

This can easily be handled by conditionally applying a version-compliant script.

NOTE: The version-compliant script should reside somewhere other than the `init.d` directory (such as a sub-directory), so it is not automatically applied.