skip to content

How does the [plugins] table work in libs.versions.toml, and how is it consumed differently from [libraries]?

level: middleimportance: should knowfreq 50%

answer

  1. [plugins]: id + version (or version.ref)
  2. id, NOT module/group+name
  3. consume in plugins {} via alias(...)
  4. libs.plugins.<alias>
  5. dash->dot accessor mapping

basics

~10 s

[plugins] entries declare a plugin id and version (e.g. id = "...", version = "..."). You consume them in the plugins {} block via alias(libs.plugins.<name>), not in dependencies {}.

solid answer

~40 s

The **[plugins]** table declares Gradle plugins for the catalog. Each entry needs an **`id`** and a version, given inline (`version = "3.2.3"`) or via `version.ref`: ```toml [plugins] spring-boot = { id = "org.springframework.boot", version = "3.2.3" } kotlin-jvm = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin" } ``` The key difference from `[libraries]` is **how you consume it**. Libraries go into the `dependencies {}` block via `libs.<alias>`. Plugins go into the **`plugins {}`** block wrapped in **`alias(...)`**: ```kotlin plugins { alias(libs.plugins.spring.boot) } ``` The `alias()` wrapper is required because the `plugins {}` block expects a plugin spec, and the catalog accessor produces a provider that `alias()` adapts. A plugin entry uses an `id`, never `module`/`group`+`name`, since plugins are identified by plugin id, not Maven coordinates.

code

kotlin · 4 lines
kotlin
plugins {
    alias(libs.plugins.spring.boot)
    alias(libs.plugins.kotlin.jvm)
}

go deeper

for a junior

Know plugins are declared with id + version and applied via alias(libs.plugins.<name>).

for a middle

Explain why alias() is needed and that plugins use id, not coordinates.

for a senior

Discuss centralizing plugin versions across modules and referencing them from convention plugins.

for a principal

Treat the [plugins] table as the org's single source for toolchain plugin versions to keep builds consistent.

## Declaring plugins in the catalog The `[plugins]` table lets the catalog own plugin versions alongside library versions, so the whole dependency surface lives in one file. Each entry is keyed by an alias and carries: - **`id`** — the Gradle plugin id (e.g. `org.springframework.boot`). This is mandatory and is the plugin's identity. Note plugins use `id`, **not** `module`/`group`+`name` — those are for libraries. - **a version** — inline `version = "3.2.3"`, a `version.ref` into `[versions]`, or a rich version object. ```toml [versions] kotlin = "1.9.23" [plugins] spring-boot = { id = "org.springframework.boot", version = "3.2.3" } kotlin-jvm = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin" } ``` ## Consuming: the plugins {} block needs alias() Libraries and plugins are consumed in **different blocks**: ```kotlin plugins { alias(libs.plugins.spring.boot) alias(libs.plugins.kotlin.jvm) } dependencies { implementation(libs.spring.core) } ``` Why the `alias(...)` wrapper? The `plugins {}` block is special — it's evaluated early and expects plugin specifications, not arbitrary providers. The catalog accessor `libs.plugins.spring.boot` is a typed provider; `alias()` is the function the plugins DSL exposes to accept it and turn it into `id(...).version(...)`. Forgetting `alias()` and writing `libs.plugins.spring.boot` bare is a common mistake that won't compile. ## Accessor naming Like libraries, plugin aliases follow the dash/dot mapping: `spring-boot` becomes `libs.plugins.spring.boot`. The `plugins` segment distinguishes them from library accessors. ## Why centralize plugin versions Keeping plugin versions in the catalog means a multi-module build applies the same plugin version everywhere and bumps it in one place. It also lets a settings plugin or convention plugin reference catalog plugin versions, keeping the whole toolchain consistent. ## Common pitfalls - Using `module` instead of `id` for a plugin entry — invalid; plugins are identified by id. - Omitting `alias()` in the `plugins {}` block. - Expecting `apply false` semantics automatically — you still control application; the catalog only supplies id+version.

  • Why must you wrap the accessor in alias() inside plugins {}?
    The plugins {} block expects a plugin spec, not a raw provider. alias() is the DSL function that adapts the catalog's typed plugin provider into an id().version() application.
  • Can a [plugins] entry use module = "group:name"?
    No. Plugins are identified by their Gradle plugin id, so a [plugins] entry must use id; module/group+name belong to [libraries].

saying these in an interview costs you the question

  • Using module/group+name in a [plugins] entry instead of id.
  • Applying a catalog plugin in dependencies {} instead of plugins {}.
  • Omitting the alias() wrapper in the plugins block.

context

resolving links…