What does the validatePlugins task do, and when does it run in a plugin build?
answer
- added by java-gradle-plugin
- static analysis of task/plugin types
- TypeValidationProblem
- wired into check
- warnings by default
basics
~10 svalidatePlugins is a task added by the java-gradle-plugin. It inspects your custom task and plugin types and reports problems such as task properties missing input/output annotations.
solid answer
~40 sWhen you apply the `java-gradle-plugin`, Gradle wires a `validatePlugins` task into the build. It statically analyses the public task and plugin types you author, checking that every getter that represents a task input or output carries a proper annotation (`@Input`, `@InputFile`, `@OutputDirectory`, etc.) and that those annotations are consistent. Problems are emitted as `TypeValidationProblem`s. The task is hooked as a dependency of `check` (transitively, via `test`/`validatePlugins` wiring), so it runs as part of `./gradlew check`. By default validation problems are reported as warnings; you can promote them to build failures. Catching missing annotations early prevents subtle correctness and up-to-date/caching bugs in the plugins you ship.
code
kotlin · 7 linesplugins {
`java-gradle-plugin`
}
// validatePlugins now runs as part of `./gradlew check`
// and reports missing/conflicting input-output annotations
// on your custom task and plugin types.go deeper
Know that java-gradle-plugin adds validatePlugins and it checks task property annotations.
Explain what it analyses (input/output annotations), that problems are TypeValidationProblems, and that it runs under check.
Connect validation to up-to-date checking and caching correctness; mention failOnWarning and validating external plugins.
Frame plugin validation as a quality gate across an org's internal plugin ecosystem, enforced in CI for all shipped plugins.
## What validatePlugins is The `java-gradle-plugin` is the plugin you apply when authoring Gradle plugins. Beyond generating plugin descriptors and providing the `gradlePlugin {}` extension, it adds a **`validatePlugins`** task. This task performs *static analysis* of the task types and plugin types declared in your project and surfaces structural problems before they bite consumers. ## Why validation matters Gradle relies on **annotations on task property getters** to know which properties are inputs and which are outputs. That metadata drives: - **Up-to-date checking** — Gradle skips a task whose inputs/outputs are unchanged. - **Build caching** — only correctly annotated tasks can be safely cached. - **Work avoidance and parallelism.** If a getter that holds an input file is missing `@InputFile` (or `@PathSensitive`), Gradle cannot track it, so the task may be wrongly considered up-to-date — a real correctness bug. `validatePlugins` flags exactly these mistakes. ## What it checks Each problem is a **`TypeValidationProblem`**. Common categories: - A property has **no annotation** declaring it an input or output. - **Conflicting annotations** (e.g. both `@Input` and `@OutputFile`). - `@Input` placed on a `File`/`RegularFileProperty` (should be `@InputFile`/`@InputDirectory`). - Missing `@PathSensitive` on file inputs (normalization unspecified). - A setter without a corresponding annotated getter; private getters annotated, etc. - Missing `@Nested`/`@Internal` where appropriate. ## When it runs ```kotlin plugins { `java-gradle-plugin` } ``` Applying the plugin wires `validatePlugins` so it executes during `./gradlew check`. By default the problems are **warnings**; the build still succeeds. You almost always want them to be errors in a plugin project (see `failOnWarning`). ## validateExternalPlugins / ValidatePlugins type The underlying task type is `org.gradle.plugin.devel.tasks.ValidatePlugins`. There is also a `ValidateExternalPlugins`-style capability used to validate already-built *external* plugin jars (the public `gradle-plugin-validation`/`validateExternalPlugins` machinery) — useful in CI to validate third-party or downstream plugins from their artifacts rather than their sources.
- Where in the task graph does validatePlugins sit?It is wired so that it runs as part of `check` (transitively through the verification lifecycle), so a normal `./gradlew check` exercises it without extra configuration.
- Are validation problems failures by default?No — by default they are emitted as warnings and the build still passes. You opt in to failing the build via failOnWarning.
saying these in an interview costs you the question
- Claiming validatePlugins runs your plugin or executes tests — it only statically analyses type metadata.
- Thinking it is on by default for every project — it requires the java-gradle-plugin.