note:

ModuleConfig

is simply a

data class

that has some properties that describe a subproject. For example, it has an

hasAndroidTests: Boolean

that is used to configure whether a subproject…has android tests. And if it does, additional tasks are configured. It also allows us to create groupings of related modules (multiple subprojects that are a part of the same feature) and then run android UI tests on just that group/feature

we also have a

ModuleConfig#isPublished

boolean so we can create a root task like

./gradlew publishAssembleDebug

(assemble the debug variant of everything we publish)

I’m currently using a statically defined list in

buildSrc

-

val Modules.ALL: List<ModuleConfig>

. I want to move away from this globally defined list, and allow each subproject to register its

ModuleConfig

itself in its own

subproject/build.gradle.kts

script. My thought process is that instead of a

List<ModuleConfig>

, create a plugin that loops over all subprojects and generates a

DomainObjectCollection<ModuleConfig>

and then allow consumers to observe it