I’m currently working on a project that has a multi-level dependency (we have root projects A, B, C, D and E, where B depends on A, C depends on A and B, D depends on A,B,C, and E depends on A,B,C,D).
Recently we moved away from direct source dependence (which was done using git submodules, a terrible way, I know, but the only solution the team at the time could come up with) to building and publishing said modules to a private Maven repo. For everyday tasks, this works great, but due to the heavy dependency between the projects, it’s hard to work on features that span across multiple modules.
Because of this, we started to implement composite builds. In case of project B, it was easy - if the path to project A is defined in local.properties, settings.gradle does an includeBuild(pathProperty), and substitutes the appropriate artifacts that were to come from Maven with the local project.
However going higher, this gets more complicated. Project C defines two blocks - one to includeBuild project A, and another to includeBuild project B. D defines 3 such blocks, and E has 4 in total. Most of these projects have at least one demo apps (we’re talking about Android projects here, and composite build is not exactly happy about having multiple com.android.app type builds spread out in multiple projects), which we’d like to exclude ONLY if the project is part of a composite build.
To make it more clear: if I run the task assembleDebug on project D, it should build the subproject app - but if I run assembleDebug on project E (which includes D as a composite), then I do not want to build :D:app at all.
I’ve found this thread which more or less covers this topic, however the specific projects are not available in settings.gradle (where the composite build setup happens), thus I can’t reference project.gradle.parent.
Is there any other way to determine if my project is part of a composite build or not? It is purely to exclude projects that are not essentially part of the composite build itself. Our current solution is using a custom isCompositeBuild property in local.properties - but it’s not optimal, because if the developer needs to just work on project C, after working on project D, they need to manually set this property (and we all know that devs are forgetful, especially with such menial tasks like changing a property…).