What are type-safe accessors in the Gradle Kotlin DSL, where do they come from, and why might one fail to resolve?

## What a type-safe accessor is In the Kotlin DSL, instead of looking things up by string at runtime, you get **generated Kotlin extensions** that expose plugin-contributed entities with their real types. Examples: - A **configuration** accessor: `implementation(...)` (a function) instead of `configurations.getByName("implementation")`. - An **extension** accessor: the `application { mainClass.set(...) }` block, where `application` is a typed property. - A **task** accessor by type: `tasks.named<Test>("test") { ... }`. Because they're typed, you get autocomplete and compile-time checks for everything inside the block. ## Where they come from Gradle's Kotlin DSL provider inspects the **plugins applied in this script's `plugins { }` block** and emits accessors for the model objects those plugins create. Key rule: **generation is driven by `plugins { }`.** If a plugin is only on the buildscript classpath, or applied imperatively via the legacy `apply(plugin = "...")`, the accessors are **not** generated. ```kotlin plugins { `java-library` // -> generates `implementation`, `api`, etc. application // -> generates the `application { }` extension accessor } dependencies { implementation("org.slf4j:slf4j-api:2.0.13") // type-safe accessor } application { mainClass.set("com.example.MainKt") // type-safe extension accessor } tasks.named<Jar>("jar") { // typed task accessor archiveBaseName.set("app") } ``` ## Why one might fail to resolve 1. **Plugin applied the legacy way.** `apply(plugin = "java-library")` applies the plugin but does **not** trigger accessor generation for the current script. Move it into `plugins { }`. 2. **Plugin only on the classpath**, e.g. declared in `dependencies { classpath(...) }` of the root buildscript but not applied here. 3. **Entity created dynamically/late** — a configuration or task created by your own script after the plugins block won't have a pre-generated accessor; use the container API. 4. **Cross-project / iteration contexts** — inside `allprojects { }`/`subprojects { }`, the receiver isn't *this* script's project model, so accessors generated for *this* script don't apply to the iterated projects. Prefer per-project scripts or convention plugins. 5. **buildSrc / precompiled script plugins** generate their own accessors from *their* plugins block; mismatches there are a common gotcha. ## The untyped fallback When no accessor exists, drop to the string-based container API: ```kotlin configurations.getByName("implementation").dependencies tasks.named("customTask") extensions.getByType<SomeExtension>().apply { /* ... */ } the<JavaPluginExtension>() // typed extension lookup helper ``` These always work but lose the compile-time guarantees, so the typed accessors are preferred whenever the plugin is applied via `plugins { }`. ## Mental model Think of accessors as a *generated typed facade* over Gradle's otherwise stringly-typed, dynamic model — the thing that makes the Kotlin DSL feel like real code instead of a config file.