عمليات البناء متعددة المشاريع وملف Settings

Real applications often split into modules — an API, a core library, a CLI. Gradle multi-project builds let one build coordinate many subprojects, sharing configuration and dependencies.

The root settings.gradle defines the build: its name and which subprojects belong to it. Without an include entry, Gradle ignores a directory.

Each included project lives in its own folder with its own build.gradle. The root build can configure them all from one place.

Use allprojects and subprojects blocks in the root build to apply shared settings, avoiding repetition.

One subproject can depend on another using the project() notation, so Gradle builds them in the right order.

Gradle builds a directed graph of project dependencies and compiles each module before the ones that need it. You never order things by hand.

From the root, gradle build builds every subproject. Target one with the project path prefix.

For large builds, enabling configuration on demand tells Gradle to configure only the projects relevant to the requested task, speeding up startup.

The special buildSrc directory holds shared build logic (custom tasks, plugins) compiled once and available to every subproject automatically.

For independent repositories, a composite build with includeBuild lets you wire separate Gradle builds together without publishing artifacts.

Independent subprojects can build at the same time. Enable parallel execution to use all CPU cores, cutting build time on large multi-project setups.

You learned to structure larger builds:

• Multi-project builds coordinate many modules
• settings.gradle includes subprojects
• subprojects/allprojects share config from the root
• project(:name) declares inter-module dependencies
• buildSrc and composite builds promote reuse