Multi-module (multi-project) builds are straight forward, since they are described by a single settings.gradle file, but attempting to aggregate them into larger comprehensive builds is not well supported at this time.
The new parallel build capability does a good job of describing decoupled items, so let’s assume that all projects/modules are decoupled between independent multi-module builds, such that logically there is a DAG also at the multi-module to other multi-module(s) level. This guarantees that combining the underlying graphs would still result in a DAG. Therefore “a” could be worked on completely independently, and then “b” just requires “a” to also be part of the larger combined checkout of work items.
multi/ ├── a/ │ ├── module-a-1/ │ ├── module-a-2/ │ └── settings.gradle ├── b/ │ ├── module-b-1/ │ ├── module-b-2/ │ └── settings.gradle └── combined.gradle
There currently is no such thing as a “combined.gradle”, and it’s actually very difficult to attempt to blend settings information programmatically. It could automatically remap the actual directory paths for the logically named modules – if there are no naming collisions.
You can make this work by hand-crafting the settings.gradle from “b” and replicating the information in “a” (plus manually re-mapping the directory paths), but that requires all commands be run relative to the “b” tree only and clearly code duplication is rarely a good pattern.
Are combined multi-module builds still being targeted for a future release? This also goes hand-in-hand with the potential ability to specify a dependency as a direct module/project output or an externally resolved dependency if the referenced project not directly part of the multi-module build tree.