Beyond isolation, what eager-evaluation and ordering pitfalls does cross-configuration cause, and how do convention plugins avoid them?

## The hidden costs of cross-config at runtime The isolation argument is the headline, but cross-configuration also creates concrete **eager-evaluation** and **ordering** problems. ### Eager iteration `subprojects { }` and `allprojects { }` iterate **all** projects when the root is configured. That eagerly realizes each project's model and frequently triggers eager work inside the block (resolving a configuration, touching a task by name). Modern Gradle pushes **lazy** configuration — create tasks with `tasks.register` (not `tasks.create`), mutate with `configureEach` (not `all`/eager `withType{}` realization), and carry values in `Provider`/`Property` so they're computed only when needed. Broad cross-config blocks cut against this grain. ### The afterEvaluate trap Cross-config often needs a child's state that isn't ready yet. For example, configuring something that depends on a plugin a child applies in *its own* script: ```kotlin subprojects { // The child applies 'java' in its own build.gradle.kts, not yet visible here, // so people defer: afterEvaluate { if (plugins.hasPlugin("java")) { extensions.configure<JavaPluginExtension> { /* ... */ } } } } ``` This is fragile: - Behavior depends on **evaluation order** (root vs each child, and the order children are evaluated). - **Stacked `afterEvaluate`** blocks run in registration order and interact in non-obvious ways. - It's easy to read or mutate values **too early or too late**, producing heisenbugs. ### Eager resolution Resolving a `Configuration` or reading a computed value inside a cross-config block at configuration time can force dependency resolution early and pull mutable state into the model — bad for both performance and the configuration cache. ## How convention plugins remove the pitfalls A convention plugin runs **inside the project that applies it**, so: - The `plugins { }` block of that project establishes plugin presence **in order, locally** — no `afterEvaluate` needed to wait for a plugin, and no cross-project ordering question. You can react to other plugins with `pluginManager.withPlugin("java") { ... }` *within the same project*, which is deterministic. - You use the **lazy** APIs naturally and scoped to one project: ```kotlin // myorg.test-conventions.gradle.kts pluginManager.withPlugin("java") { tasks.withType<Test>().configureEach { useJUnitPlatform() } } ``` - No eager iteration over `subprojects`; each project configures itself once, lazily. The payoff is **deterministic, lazier, faster** configuration that the configuration cache can serialize and reuse per project. So the convention-plugin preference isn't only philosophical isolation — it removes a class of real ordering bugs and performance drags.