An improper way to share build logic between subprojects is _cross-project configuration_ via the link:{javadocPath}//org/gradle/api/Project.html#subprojects-groovy.lang.Closure-[`subprojects {}`] and link:{javadocPath}/org/gradle/api/Project.html#allprojects-groovy.lang.Closure-[`allprojects {}`] DSL constructs.

TIP:  Avoid using `subprojects {}` and `allprojects {}`.

        } else {
            int chosenSubprojectNumber = subprojects.size() / 2
            def subproject = subprojects[chosenSubprojectNumber]
            def fName = "project${subproject.subprojectNumber}lib${chosenSourceFileNumber}"
            cppFile = "${subproject.name}/src/main/cpp/${fName}.cpp"
            headerFile = "${subproject.name}/src/main/public/${fName}.h"
        }

        """
            defaults {

rootProject.name = '${rootProjectName}'
<%
subprojects.each { subproject ->
    out.println "include '$subproject'"
}
%>

<3> Gradle wrapper scripts
<4> Gradle settings file to define a root project name and subprojects
<5> Gradle build scripts of the two subprojects - `subproject-a` and `subproject-b`
<6> Source code and/or additional files for the projects

== Invoking Gradle

=== IDE

* Create a modular software project by combining multiple subprojects
* Share build configuration logic between subprojects using convention plugins in `buildSrc`
* Run similar named tasks in all subprojects
* Run a task in a specific subproject
* Build, bundle and run the application

== Next steps

When your project grows, you might be interested in more details how to configure JVM projects, structuring multi-project builds and dependency management:

        generateRootProject()
        subprojects.each { subproject ->
            if (repo) {
                subproject.setRepository(repo)
                pickExternalDependencies(repo, subproject)
            }
            generateSubProject(subproject)
        }

        generateScriptPlugins()
    }

    void generateScriptPlugins() {

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 when applied to the distribution project, such as an Android application or WAR subproject.

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 when applied to the distribution project, such as an Android application or WAR subproject.

<3> Gradle wrapper start scripts
<4> Settings file to define build name and subprojects
<5> Build script for `app` subproject
<6> Default Java source folder for `app` subproject
<7> Default Java test source folder for `app` subproject
=====

The `authoring-tutorial` folder is the *root project directory*.
Inside the root project directory are one or more subprojects, build scripts, and the Gradle wrapper.

- `settings.gradle(.kts)` file representing your Gradle build including required subprojects e.g. include("app", "model", "service")
- `build.gradle(.kts)` and source code for each subproject in corresponding subdirectories

Our build currently consists of a root project called `authoring-tutorial`, which has a single `app` subproject:

[.multi-language-sample]
=====
[source, kotlin]
----
.   // <1>
├── app // <2>