การสร้างแบบผสมและการประกอบการสร้าง

A composite build stitches multiple otherwise-independent Gradle builds together. Unlike subprojects, each included build keeps its own settings.gradle and lifecycle.

• Subprojects: one build, many modules
• Composite: many builds, joined on demand

Composite builds shine when you work across repository boundaries:

• Develop a library and its consumer side by side
• Avoid publishing SNAPSHOTs just to test a change
• Debug a plugin in the context of a real project

You join another build with includeBuild in settings.gradle. The path points at a directory containing its own settings file.

The magic is automatic dependency substitution. When your project declares a dependency on a module that an included build produces, Gradle wires the in-source build in place of the published artifact.

If group/name do not match, declare the mapping manually so Gradle knows which project replaces the coordinate.

You can invoke tasks from an included build using the :buildName:task syntax from the root.

Use a multi-project build when modules always ship together. Use a composite when builds are independently versioned and released but you occasionally need them linked.

Composite builds are the recommended way to test a custom plugin. Include the plugin build, and consuming projects pick up your local changes instantly.

IntelliJ IDEA and Android Studio import composite builds as a single workspace, so navigation, refactoring, and debugging span all included builds seamlessly.

A few constraints apply:

• Included builds cannot themselves define the same root build
• A build cannot include itself (no cycles)
• Publishing tasks are not substituted, only consumable artifacts

Keep composites ergonomic:

• Use relative paths so teammates can clone side by side
• Keep coordinates consistent to rely on automatic substitution
• Document which builds are expected to be included

You learned composite builds:

• includeBuild joins independent builds
• Dependency substitution swaps artifacts for live source
• Ideal for cross-repo and plugin development
• Differs from multi-project: builds stay independently versioned