From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

+1 it wasn't clear in the docs for me as well.

<https://docs.gradle.org/current/userguide/multi_project_configuration_and_execution.html#sec:decoupled_projects> mention that if the `allprojects/subprojects` are limited to your `rootProject` then at least configuration on demand is not affected

it is not affected because with configuration on demand the root project is always configured anyway. But if you for example have root project with child project A that has child project B. If you use configure on demand and execute a task in B, then A is not configured but only the root project and B. So if you use an `allprojects { ... }` or `subprojects { ... }` block in A where you inject configuration into B, then when using configure on demand that configuration is missing.

So if you use either of these, you automatically couple the involved projects.

Just don't do it and better use convention plugins, that also makes the build logic clearer, because you look at a build script and see all relevant logic / plugins. If you inject build logic from other projects, then you need to look around where configuration comes from.

Ok, I see better now. Thanks for the detailed answer! :slightly_smiling_face: