skip to content

How can you validate plugins you did not author from their built artifacts, and why would you?

level: seniorimportance: nice to knowfreq 20%

answer

  1. validate plugins you didn't author
  2. point at external classes/classpath
  3. same TypeValidationProblem checks
  4. supply-chain / CI gate
  5. validate the published artifact

basics

~20 s

Use Gradle's external-plugin validation (a ValidatePlugins-style task pointed at the plugin classes/jars rather than your own sources). It runs the same TypeValidationProblem checks on third-party or downstream plugins so you can gate them in CI.

solid answer

~40 s

`validatePlugins` normally analyses the task/plugin types compiled in your own project. But you sometimes want to validate plugins you *didn't* author — third-party plugins, or already-built artifacts produced elsewhere. Gradle supports this by running the same validation machinery against external plugin classes (resolved from their jars/classpath) instead of your local sources. The checks are identical `TypeValidationProblem`s — missing/conflicting input-output annotations, missing normalization — and you can apply `failOnWarning` to gate. The motivation is supply-chain and build-correctness assurance: a poorly annotated external plugin silently breaks up-to-date checking and caching in *your* build. Running external validation in CI lets a platform team certify the plugins their org depends on, or a plugin author validate the *published* artifact (not just the source) before release.

code

kotlin · 9 lines
kotlin
import org.gradle.plugin.devel.tasks.ValidatePlugins

val externalPluginClasspath by configurations.creating
dependencies { externalPluginClasspath("com.example:some-plugin:1.2.3") }

tasks.register<ValidatePlugins>("validateExternalPlugin") {
    classpath.setFrom(externalPluginClasspath)
    failOnWarning = true
}

go deeper

for a junior

Just know validation normally targets your own plugin types.

for a middle

Understand that the same checks can be pointed at external plugin classes, with failOnWarning.

for a senior

Explain the supply-chain/build-correctness motivation and validating the published artifact.

for a principal

Position external validation as an org-wide certification gate for the plugins many repos depend on.

## The gap external validation fills The ordinary `validatePlugins` task validates the types **your project compiles**. That is perfect while authoring, but it doesn't help when: - You **consume third-party plugins** and want assurance their tasks are correctly annotated (a badly annotated dependency plugin corrupts your build's incremental behaviour). - You want to validate the **published artifact** itself — the jar consumers actually download — rather than your pre-package sources. - A platform/build-tooling team wants to **certify** the catalogue of plugins used across many repos. ## How external validation works Gradle exposes machinery to run the same validation against external plugin classes. Conceptually you point a `ValidatePlugins`-style task at a *classpath* of already-built plugin classes (resolved as a dependency/artifact) instead of the local `sourceSets` output. It loads those types and emits the identical `TypeValidationProblem` set. Because it's the same analysis, `failOnWarning` and stricter validation apply equally. ```kotlin // Sketch: resolve the external plugin's classes and validate them val externalPluginClasspath by configurations.creating dependencies { externalPluginClasspath("com.example:some-plugin:1.2.3") } tasks.register<ValidatePlugins>("validateExternalPlugin") { classes.setFrom(/* extracted classes dir from the artifact */) classpath.setFrom(externalPluginClasspath) failOnWarning = true } ``` ## Why bother — the value - **Build correctness as a supply-chain property.** Incremental build and caching correctness depend on every task type on the classpath, not just yours. One untracked input in a dependency makes your outputs stale. - **Certify before adopt.** A platform team can refuse to onboard a plugin that fails validation. - **Validate the real artifact.** Authors validate what they actually ship, catching annotation processing or packaging issues that don't appear in source-level validation. ## Relationship to local validation Same rules, same `TypeValidationProblem` categories, same `failOnWarning`/`enableStricterValidation` switches — only the *input* differs (external classes vs. your `sourceSets`). Treat it as the CI-side counterpart to authoring-time validation.

  • Why validate the published artifact rather than the source?
    The jar is what consumers actually load. Packaging, annotation processing, or relocation issues can differ from source-level analysis, so validating the artifact catches problems that source validation misses.
  • What's the build-correctness risk of an unvalidated dependency plugin?
    Incremental build and cache correctness depend on every task type on the classpath. An untracked input in a dependency plugin can make your build wrongly skip work and ship stale outputs.

saying these in an interview costs you the question

  • Saying external validation runs the plugin — it still only statically analyses type metadata.
  • Assuming you can only validate your own sources.

context

resolving links…