The build is then included in the root project's _settings_ file as seen in the above snippet.
For more details about included builds, see link:{userManualPath}/composite_builds.html[Composing Builds] chapter.

The `myproject.java-conventions` plugin is then applied to the `buildSrc` build:
====
include::sample[dir="kotlin",files="buildSrc/build.gradle.kts[tags=plugins]"]

        private PluginResolution resolveFromIncludedPluginBuilds(PluginId requestedPluginId) {
            for (IncludedBuildState build : buildIncluder.getRegisteredPluginBuilds()) {
                buildIncluder.prepareForPluginResolution(build);
                Optional<PluginResolution> pluginResolution = build.withState(gradleInternal -> LocalPluginResolution.resolvePlugin(gradleInternal, requestedPluginId));

     *
     * <p>If the target Gradle version is &gt;=6.8 then you can execute tasks from included builds. You can target tasks from included builds by specifying the task identity path (i.e. {@code
     * ':included-build-name:subproject-name:taskName'}).</p>
     *

        when:
        run ":projects"

        then:
        outputContains """
Root project 'my-root-project'
No sub-projects

Included builds:

+--- Included build ':another'
\\--- Included build ':third'"""
    }

    def "included builds are only shown in the context of the root project"() {
        given:
        createDirs("p1", "p1/p11", "another")

This way, the configuration time of a large multi-project build can be reduced.

The configuration-on-demand feature is _incubating_, so only some builds are guaranteed to work correctly.
The feature works well for <<#sec:decoupled_projects,decoupled>> multi-project builds.

	"k8s.io/kubernetes/pkg/scheduler/framework"
	frameworkruntime "k8s.io/kubernetes/pkg/scheduler/framework/runtime"
)

// RecorderFactory builds an EventRecorder for a given scheduler name.
type RecorderFactory func(string) events.EventRecorder

// newProfile builds a Profile for the given configuration.
func newProfile(ctx context.Context, cfg config.KubeSchedulerProfile, r frameworkruntime.Registry, recorderFact RecorderFactory,

				b.Args = append(b.Args, args)
			}
			builds = append(builds, b)
		}
	}

	// Warm up our base images while we are building everything. This isn't pulling them -- we actually
	// never pull them -- but it is pulling the config file from the remote registry.
	builder.WarmBase(ctx, a.Architectures, sets.SortedList(bases)...)

	// Build all dependencies
	makeStart := time.Now()

+
At this point, you should be able to switch to using proper project dependencies attached to the appropriate dependency configurations.
 7. Clean up projects once no part of the Ant build depends on them.
+
We mentioned in step 5 that you might need to add copy tasks to satisfy the requirements of dependent Ant builds.
Once those builds have been migrated, such build logic will no longer be needed and should be removed.

    }

    @Requires(IntegTestPreconditions.NotParallelExecutor)
    @UnsupportedWithConfigurationCache(because = "parallel by default")
    def "reuses compiler daemons within a multi-project build across multiple builds when enabled"() {
        withMultiProjectSources()
        withPersistentScalaCompilerDaemons()

        when:
        succeeds("compileAll")

        then:

== Step 4. Understanding Remote Caching
In addition to the local build cache present on a developer's machine, Gradle can make use of remote build caches which can be used by multiple developers.

The idea of a remote cache is to share commonly built task outputs across remote builds to improve build times.

When both remote and local caches are enabled, then the build output is first checked in the local cache.