Applying Plugins

apply(plugin = "...") is the old imperative way to apply a plugin by ID anywhere in the build script. The modern plugins {} DSL is a declarative block at the top that Gradle understands ahead of time.

The plugins {} block is the declarative way to apply Gradle plugins. Use id("...") for a plugin, adding version "..." for community plugins. Core plugins like java need no version.

Use id("com.example.foo") version "1.2.3" inside plugins {}. Gradle resolves the plugin from the Gradle Plugin Portal (or repositories declared in settings' pluginManagement) by looking up its marker artifact.

Requesting the same plugin version in two projects sharing a classpath conflicts. You fix it by requesting the version once at the root with apply false, then applying by id (no version) in each subproject.

Gradle turns the plugin id into a tiny marker module <id>:<id>.gradle.plugin whose POM has no code — it only depends on the real implementation jar. The marker redirects; the implementation jar contains the plugin classes.

buildscript { dependencies { classpath(...) } } adds a plugin's implementation to the classpath used to run the build script itself. The regular dependencies {} block adds libraries to your compiled application, not to the build script.

Gradle parses the plugins {} block in a special early pass before running the rest of the script, so it must come first (only buildscript {} may precede it). Otherwise you get a compilation error: 'only buildscript {} and other plugins {} script blocks are allowed before plugins {} blocks'.

In the convention plugin's apply(), wrap the Java config in pluginManager.withPlugin("java") { ... }. It runs only for consumers that apply java, and skips others — so the plugin doesn't force java on anyone.

Because the java plugin might not be applied yet (or at all). withPlugin defers your configuration so it only runs when/if that plugin is present, instead of failing or forcing an apply order.

You omit the version when it's already resolved elsewhere: core Gradle plugins (bundled), plugins versioned in settings' pluginManagement.plugins {}, or a version brought in by a parent/root project. Gradle reuses that already-known version.

Define the plugin under [plugins] in gradle/libs.versions.toml (id + version, version can reference [versions]). Then in plugins {} write alias(libs.plugins.x). Gradle generates the typesafe libs accessor and supplies the version from the catalog.

plugins {} applies build logic (tasks, conventions) to the build itself; dependencies {} declares libraries your application/tests compile and run against. One shapes the build; the other shapes the program.

The root is usually an aggregation project with no source. Applying a code plugin there creates source sets, compile tasks and extensions you don't want. apply false resolves the plugin without activating those on the root.

The version moves into [plugins] in libs.versions.toml. The root writes alias(libs.plugins.kotlin.jvm) apply false; subprojects write alias(libs.plugins.kotlin.jvm). The apply false resolve-but-don't-activate mechanic is unchanged.

Gradle builds the marker coordinate com.gradle.develocity:com.gradle.develocity.gradle.plugin:<v>, fetches that POM from the pluginManagement repos (Portal by default), reads its single dependency, downloads the implementation jar, and loads the plugin class onto the build's classpath.

Use apply<MyPlugin>() to apply a plugin by its class when you have the class on the classpath (e.g. a buildSrc or included-build plugin). Use apply(plugin = "id") to apply by string ID when you only know the ID.

apply(from = ...) applies a script plugin — it runs another build script file in the context of the current project, as if its contents were inlined. It's a simple way to share build logic across scripts.

apply false brings a plugin's version onto the build's plugin classpath without actually applying it to that project. It's mainly used in a root build script to fix versions for subprojects that apply the plugin themselves.

The plugins {} block accepts only the constrained plugins DSL — id(...), version, apply false. No conditionals, loops, variables, or arbitrary method calls. Imperative apply(plugin = "...") is normal Kotlin code, so it can be wrapped in if blocks or loops.

Convention plugins live in a separate build-logic module and apply third-party plugins by id (no version). The root apply false (or the build-logic module's dependency on the plugin marker) is what pins the version so the convention plugin can resolve it.

The plugins {} block uses an id and resolves it through the marker module. The legacy buildscript { classpath(...) } + apply(plugin = ...) approach puts the implementation coordinate directly on the classpath, so no marker is involved — you reference the real jar by GAV.

Use legacy apply() when applying to other projects programmatically (subprojects/allprojects), applying a local plugin class by type, applying a script plugin via apply(from=), or applying a plugin that has no marker artifact and needs a buildscript classpath.

Gradle extracts plugins {} early, resolves each plugin's marker/version, builds a plugin classpath, applies the plugins (adding tasks/extensions), and generates type-safe accessors before running the script body. At scale, you push it into convention plugins + version catalogs for one governed version surface.

Nest reactions: react to java with withPlugin("java") to add the source set, and inside (or separately) react to jacoco with withPlugin("jacoco") to wire the report. Each block runs only when its plugin is present, so both conditions must hold.

afterEvaluate delays all your config to the end of configuration and runs even if nothing changed; withPlugin runs exactly when the plugin appears, is lazy and ordering-safe, and avoids the timing pitfalls and lifecycle fragility of afterEvaluate.

withPlugin keys off the plugin's id string; withType keys off its class. Use withPlugin for third-party plugins not on your classpath; use withType when you have the plugin type and want a typed, refactor-safe reference.

Find every place the plugin's version is declared (catalog, settings pluginManagement, root and module plugins blocks). Keep exactly one declaration as the source of truth, omit the version everywhere else, and re-run the build.

Declare every plugin version once in gradle/libs.versions.toml under [plugins]. Resolve them at the root with alias(...) apply false (or use convention plugins), then apply by alias with no version in each module. This keeps versions DRY and conflict-free.

Yes. One jar can register many ids — each gets its own META-INF/gradle-plugins/<id>.properties descriptor and, on publish, its own marker module, all depending on the same implementation jar. Consumers apply whichever id they need.