How does cross-configuration with subprojects { } / allprojects { } interfere with Gradle's configuration cache?

## What the configuration cache is The **configuration cache** is a Gradle feature that serializes the result of the *configuration phase* (the task graph and configured task state) to disk. On the next compatible invocation, Gradle skips configuration entirely and goes straight to execution, which can dramatically speed up builds — especially large multi-project ones. ## The invariant it relies on For the cache to be correct and to enable **parallel project configuration** (under the incubating **Project Isolation** feature), Gradle wants each project's configuration to be a pure function of **that project's own declared inputs** (its build script, its `gradle.properties`, value sources, etc.). If that holds, Gradle can: - configure projects **independently** (and in parallel), - **cache** each project's configuration separately, - **invalidate** only the projects whose own inputs changed. ## How cross-configuration breaks the invariant With `subprojects { }`/`allprojects { }`, the **root** build script contains code that mutates child projects: ```kotlin subprojects { tasks.withType<Test>().configureEach { useJUnitPlatform() } } ``` Now a child project's configured state is **not** purely a function of its own inputs — it is produced by the root. Effects: - The **root becomes an input** to every child's configuration, entangling cache entries and serializing what could have been independent work. - Gradle cannot safely **isolate** or **parallelize** per-project configuration, because configuring one project requires running the root's cross-config code. - Invalidation gets coarser: a change in the root's cross-config can invalidate *all* projects. - Cross-config blocks often pull broad, **eagerly-evaluated** state (project references, resolved values) into the model, which is exactly the kind of thing the cache must serialize and the lazy `Provider`/`Property` APIs try to avoid. ## Important nuance The configuration cache does **not** outright reject `subprojects { }` in every case — many builds run with both. But you lose the **isolation and parallel-configuration** benefits, and you make it easier to write captured-state patterns the cache can't serialize. The clean path is convention plugins. ## Convention plugins restore the invariant When shared logic lives in a convention plugin that each project applies to itself, each project's configuration is again self-contained: ```kotlin // subproject build.gradle.kts plugins { id("myorg.test-conventions") } ``` The plugin's code runs *within that project's* configuration, keyed on that project's inputs. The cache can store and reuse each project independently — and Project Isolation can run them in parallel.