You need to configure a multi-project build with Gradle. What considerations would you take into account?

Question

Accepted Answer

Configuring a multi-project Gradle build involves organizing subprojects in a directory structure, registering them in settings.gradle, and deciding what configuration lives in the root build.gradle versus each subproject. Good structure keeps shared logic centralized while letting each module control its own specifics.

Key Points:
• settings.gradle declares which directories are subprojects using include statements, e.g. include 'api', 'core', 'web'.
• The root build.gradle can use allprojects or subprojects blocks to apply shared repositories, plugins, or dependency versions.
• Prefer subprojects over allprojects for configuration that shouldn't apply to the root project itself.
• Each subproject keeps its own build.gradle for module-specific dependencies and tasks, avoiding an overly bloated root file.
• Inter-project dependencies use project(':moduleName') references instead of external coordinates.
• Consider using a version catalog (libs.versions.toml) to share dependency versions consistently across all subprojects without magic strings.

Example:
A backend split into api, service, and persistence subprojects can share a common Java version and test framework via a subprojects block in the root build.gradle, while each module still declares its own unique dependencies like a database driver only needed in persistence.

Code Example:
```
// settings.gradle
rootProject.name = 'my-app'
include 'api', 'service', 'persistence'

// root build.gradle
subprojects {
    apply plugin: 'java'
    repositories { mavenCentral() }
    dependencies {
        testImplementation 'org.junit.jupiter:junit-jupiter:5.10.2'
    }
}
```

Interview Tip:
A concise interview answer is:

"I'd register each subproject in settings.gradle, then use a subprojects block in the root build.gradle for shared plugins, repositories, and dependency versions, leaving module-specific configuration in each subproject's own build.gradle. For cross-module dependencies I'd use project() references rather than duplicating logic, and a version catalog to keep dependency versions consistent."