How do you find a plugin's correct id and version on the Gradle Plugin Portal, and what snippet do you copy into your build?
answer
- search portal by id/keyword
- page shows id + latest version
- copy plugins {} snippet
- /m2/ endpoint for legacy
- version catalog [plugins]
basics
~10 sSearch plugins.gradle.org by name or id; the plugin's page shows its id, latest version, and a copy-paste snippet for the plugins {} block that you drop into build.gradle(.kts).
solid answer
~40 sOn `plugins.gradle.org` you search by keyword or by the reverse-DNS **id**. Each plugin page lists the canonical **id**, the **latest version** (and the version history), and ready-made snippets for both the modern **plugin DSL** and the legacy `buildscript`+`apply` style. For the plugins {} block you copy something like `id("org.springframework.boot") version "3.3.0"` into `build.gradle.kts`. The page also shows compatibility notes and the implementation coordinates. Picking the id and version off the portal — rather than guessing — avoids typos in the id (which fail resolution with a clear "plugin not found in any of the following sources" message) and ensures you pin a published version. For version-catalog setups you put the id+version under `[plugins]` in `libs.versions.toml` and reference it as `alias(libs.plugins.spring.boot)`.
code
toml · 4 lines# gradle/libs.versions.toml
[plugins]
spring-boot = { id = "org.springframework.boot", version = "3.3.0" }
spotless = { id = "com.diffplug.spotless", version = "6.25.0" }go deeper
Know you search the portal site and copy the plugins {} snippet with id and version.
Mention the two snippet forms and putting id/version into a version catalog.
Explain ids are case-sensitive/exact and how resolution failures report the searched sources.
Discuss governing which versions/ids teams may adopt and curating an approved list rather than ad-hoc portal copying.
## Discovering plugins on the portal The portal website offers full-text search across plugin ids, display names, descriptions, and tags. Typing a tool name (e.g. `spotless`) surfaces the plugin, and the result page is the authoritative source for: - the canonical **plugin id** (reverse-DNS, case-sensitive), - the **latest version** plus a dropdown of all published versions, - copy-paste **usage snippets**, - the underlying implementation coordinates and any documentation links. ## The two snippet forms Every plugin page shows both styles: ```kotlin // Modern plugin DSL (preferred) plugins { id("com.diffplug.spotless") version "6.25.0" } ``` ```groovy // Legacy buildscript + apply (for special cases) buildscript { repositories { maven { url = uri("https://plugins.gradle.org/m2/") } } dependencies { classpath "com.diffplug.spotless:spotless-plugin-gradle:6.25.0" } } apply plugin: "com.diffplug.spotless" ``` Use the **plugin DSL** form unless you must apply a plugin conditionally or to multiple projects programmatically. ## Version catalogs For multi-module builds, declare the plugin once in `gradle/libs.versions.toml`: ```toml [plugins] spotless = { id = "com.diffplug.spotless", version = "6.25.0" } ``` then apply with `alias(libs.plugins.spotless)`. The id/version still come from what you found on the portal. ## Why use the portal's exact values Plugin ids are case-sensitive and resolved exactly. A wrong id or an unpublished version yields a resolution failure listing the repositories searched. Copying from the portal page eliminates that class of error and confirms the version actually exists. ## The m2 endpoint The portal exposes a Maven-compatible endpoint at `https://plugins.gradle.org/m2/`. That URL is what the legacy `buildscript` snippet points at, and it's also useful when you must reference the implementation jar directly.
- What error do you get if the plugin id is misspelled?Gradle fails the build with 'Plugin [id: ...] was not found in any of the following sources' and lists the searched repositories, because no matching marker exists.
- What is the https://plugins.gradle.org/m2/ URL used for?It's the portal's Maven-compatible repository endpoint, used by legacy buildscript classpath declarations and when referencing implementation jars directly.
saying these in an interview costs you the question
- Treating the plugin id as case-insensitive.
- Recommending the legacy buildscript/apply form as the default instead of the plugins {} DSL.