Избавляемся от бинарных зависимостей с композитной сборкой в Gradle 3.1

[@xkor]

Композитные сборки позволяют:

• Быстро подложить исправленную версию исходников библиотеки в другой проект без необходимости собирать её, опубликовывать и править сборку.
• Делить большие проекты на несколько небольших, изолированных сборок, над каждой из которых можно работать как по отдельности, так и одновременно.
• Отделить разработку плагина для системы сборки от проекта, его использующего (аналог buildSrc)

А что то из этого не позволяют сделать многопроектные сборки?

[@saladinkzn]

Многопроектная сборка — это дерево в файловой системе. Композитные сборки же позволяют разделить собираемые проекты в файловой системе со всеми вытекающими отсюда преимуществами.

К тому же, у Gradle появляются гарантии, что включаемые сборки не зависят друг от друга, поэтому они собираются сделать возможность запускать их параллельно — а это уже должно дать прирост к производительности

[@Prototik]

Многопроектная сборка — это дерево в файловой системе

Ну, формально нет, проекты можно было тянуть из совершенно раных мест. Этот composite builds — лишь сахар над многопроектной сборкой, имхо. Я не говорю, что он бесполезен, но и новых возможностей он не привносит.

[@saladinkzn]

Этот composite builds — лишь сахар

Тут есть отличие в том, что:

Included builds do not share any configuration with the composite build, or the other included builds. Each included build is configured and executed in isolation.

Но, вообще говоря, да: это комбинация из фичи с подстановками + возможность делать include из командной строки.

То есть никто не мешает сделать тоже самое, не используя Composite build: создать проект, заинклюдить туда :lib1 и :app и сделать Dependency Substituion.