skip to content

What does `apply false` mean in a plugins {} block, and when would you use it?

level: middleimportance: should knowfreq 52%

answer

  1. resolve version, don't apply here
  2. root declares apply false
  3. subprojects apply bare id, inherit version
  4. centralized version management
  5. pairs with version catalog alias

basics

~20 s

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.

solid answer

~40 s

In a `plugins {}` block, `id("...") version "..." apply false` resolves and adds the plugin to the build's plugin classpath but does **not** apply it to the current project — no tasks/extensions are added there. The classic use is the **root project** of a multi-project build: you declare each external plugin once with `apply false` (pinning its version centrally), and then each subproject applies it with a bare `id("...")` (no version), inheriting the version from the root declaration. This gives one source of truth for plugin versions while letting each module opt in. Without `apply false` on the root, the root would itself get the plugin applied, which is usually unwanted. It's the declarative equivalent of centralizing plugin versions, often paired with a version catalog (`alias(libs.plugins.foo) apply false`).

code

kotlin · 10 lines
kotlin
// root build.gradle.kts — pin versions, don't apply
plugins {
    id("org.springframework.boot") version "3.2.0" apply false
}

// any subproject — apply, version inherited
plugins {
    java
    id("org.springframework.boot")
}

go deeper

for a junior

Know apply false means 'bring the plugin's version in but don't apply it here'.

for a middle

Explain the root-declares-once, subprojects-apply-bare pattern for centralizing versions.

for a senior

Connect it to version catalogs (alias(...) apply false) and why it beats repeating versions per module.

for a principal

Frame it as part of a build-platform strategy: one governed version surface across many modules.

## The problem it solves In a multi-project build, several subprojects may need the same external plugin (say `org.springframework.boot`). You want **one place** that pins its version, but you don't necessarily want the root project itself to have the plugin applied. ## What `apply false` does `id("org.springframework.boot") version "3.2.0" apply false`: - **Resolves** the plugin artifact and puts it on the build's shared plugin classpath. - Records the **version** so other scripts can reference the same ID without restating it. - Does **not** apply the plugin to the project containing this `plugins {}` block (no tasks, no extension there). ## The canonical pattern ```kotlin // root build.gradle.kts plugins { id("org.springframework.boot") version "3.2.0" apply false id("io.spring.dependency-management") version "1.1.4" apply false } // subproject build.gradle.kts plugins { java id("org.springframework.boot") // no version — inherited from root id("io.spring.dependency-management") } ``` The subproject omits the version: it resolves to the version declared (with `apply false`) at the root. This centralizes version management. ## With version catalogs Version catalogs make this even cleaner: ```kotlin // root plugins { alias(libs.plugins.springBoot) apply false } // subproject plugins { alias(libs.plugins.springBoot) } ``` ## Common confusion - `apply false` does NOT mean "disable" the plugin everywhere — it just skips application **here** while still making the versioned plugin available. - A subproject that never applies the plugin simply doesn't list it; `apply false` at the root has no effect on those modules.

  • Why does the subproject omit the version when the root used apply false?
    The root's apply-false declaration already added the versioned plugin to the build's plugin classpath, so subprojects reference the same ID without restating (and risking diverging) the version.
  • Does apply false add any tasks to the root project?
    No — it deliberately skips applying the plugin to that project, so no tasks or extensions are contributed there.

saying these in an interview costs you the question

  • Saying apply false disables the plugin for the whole build.
  • Putting a version on the subproject's id when the root already declared it with apply false (can cause a version conflict).

context

resolving links…