* See {@code subprojects/core-api/src/main/java/org/gradle/package-info.java} for an example.
     * <p>
     * Note that adding the annotation for a package in one subproject will automatically apply it for the same package in all other subprojects.
     * Therefore, it's advised to add the annotation to the package in the most appropriate subproject.

```

Note that the samples are also used in `samples` subproject, see [`@UsesSample`](https://github.com/gradle/gradle/blob/9ade1a05427aaf04c976a0e85814b44b3435f9f9/subprojects/internal-integ-testing/src/main/groovy/org/gradle/integtests/fixtures/UsesSample.java#L25) and [`Sample`](https://github.com/gradle/gradle/blob/903c5f2cee88c9768077d46025eaafdf65862fc8/subprojects/internal-integ-testing/src/main/groovy/org/gradle/integtests/fixtures/Sample.java#L37).

        def javaHome = AvailableJavaHomes.availableJvms[0].javaHome.absolutePath

        buildTestFixture.withBuildInSubDir()
        def subproject = "app"
        def subprojects = [subproject]
        def rootProject = multiProjectBuild("project", subprojects) {
            buildFile << """
                import org.gradle.internal.jvm.inspection.JavaInstallationRegistry;

        where:
        repoType << [IVY, MAVEN]
    }

    def "can apply plugin from #repoType repo to subprojects"() {
        given:
        publishTestPlugin(repoType)
        buildScript """
          plugins {
              id "org.example.plugin" version "1.0" apply false
          }

          subprojects {
            apply plugin: 'org.example.plugin'
          }
        """

        and:

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

<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.

Consult the <<directory_layout.adoc#dir:project_root,Gradle Directories reference>> to learn more.

[.text-right]

        buildTestFixture.singleProjectBuild(projectName, cl)
    }

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

This sample shows how to aggregate code coverage across multiple Java subprojects using link:https://www.jacoco.org/jacoco/[JaCoCo].  The link:{userManualPath}/jacoco_report_aggregation_plugin.html[jacoco-report-aggregation plugin] provides this ability via a standalone project used to specify _which_ subprojects to include for aggregation.

This sample shows how to aggregate test results across multiple Java subprojects.  The link:{userManualPath}/test_report_aggregation_plugin.html[test-report-aggregation plugin] provides this ability via a standalone project used to specify _which_ subprojects to include for aggregation.

        steps {
            script {
                // Because we exclude tests in `distributions-integ-tests` below, `@Flaky` won't work in that subproject.
                // Here we check the existence of `@Flaky` annotation to make sure nobody use that annotation in `distributions-integ-tests` subproject.
                name = "MAKE_SURE_NO_@FLAKY_IN_DISTRIBUTIONS_INTEG_TESTS"
                executionMode = BuildStep.ExecutionMode.ALWAYS