It is the same way not transitive as repository declarations are not

Ok, I must have confused something somewhere. The included build is working transitively. So if the top build uses

libraryB

and only

featureA

is including that build, it is still substituted from the included build. But that note in the docs is mainly majorly confusing.

gradle.parent

of

libraryB

and

featureA

is both the top-level build, that is meant with flattening And if you refer to tasks from the builds from the commandline it is

:featureA:build

and

:libraryB:build

, that is also meant with flattening. But

gradle.includedBuilds

for the top build contains only

featureA

and for

featureA

contains

libraryB

. And also with

gradle.includedBuild(...)

you can only access

featureA

from the top build and

libraryB

from

featureA

. So there no flattening is done but the tree is preserved. That seems to be a bit inconsistent. 🤷‍♂️ So if you want to access tasks of the included build, you can indeed only access tasks from builds directly included in the same build. So for that you would indeed need to include

libraryB

in the top-level build too. Or alternatively you need to have the reference in

featureA

in a way that you can refer to that from the top-level build.

hmm. although i guess what you’re suggesting is I could build that from the bottom up, rather than top-down like i’m trying to do right now. so that

featureA

would itself declare a task that

dependsOn

whatever I want from

libraryB

, and so on up the chain