Comments 5
Композитные сборки позволяют:
- Быстро подложить исправленную версию исходников библиотеки в другой проект без необходимости собирать её, опубликовывать и править сборку.
- Делить большие проекты на несколько небольших, изолированных сборок, над каждой из которых можно работать как по отдельности, так и одновременно.
- Отделить разработку плагина для системы сборки от проекта, его использующего (аналог buildSrc)
А что то из этого не позволяют сделать многопроектные сборки?
Многопроектная сборка — это дерево в файловой системе. Композитные сборки же позволяют разделить собираемые проекты в файловой системе со всеми вытекающими отсюда преимуществами.
К тому же, у Gradle появляются гарантии, что включаемые сборки не зависят друг от друга, поэтому они собираются сделать возможность запускать их параллельно — а это уже должно дать прирост к производительности
К тому же, у Gradle появляются гарантии, что включаемые сборки не зависят друг от друга, поэтому они собираются сделать возможность запускать их параллельно — а это уже должно дать прирост к производительности
Многопроектная сборка — это дерево в файловой системе
Ну, формально нет, проекты можно было тянуть из совершенно раных мест. Этот composite builds — лишь сахар над многопроектной сборкой, имхо. Я не говорю, что он бесполезен, но и новых возможностей он не привносит.
Этот 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.
UFO just landed and posted this here
Sign up to leave a comment.
Избавляемся от бинарных зависимостей с композитной сборкой в Gradle 3.1