skip to content

What kinds of problems does plugin validation report, and what is a TypeValidationProblem?

level: seniorimportance: should knowfreq 38%

answer

  1. one problem per type/property
  2. missing annotation
  3. conflicting @Input/@Output
  4. @Input on File is wrong
  5. missing @PathSensitive / @Nested

basics

~10 s

A TypeValidationProblem is a single issue validatePlugins found on a task or plugin type — most often a property with no input/output annotation, or conflicting annotations like both @Input and @OutputFile on one getter.

solid answer

~40 s

`TypeValidationProblem` is the structured representation of one issue `validatePlugins` finds when analysing a task or plugin type. The common categories are: a **mutable property with no annotation** (Gradle can't tell if it's an input or output, so up-to-date checking is broken); **conflicting annotations** (e.g. both `@Input` and `@OutputFile`); using `@Input` on a file-typed property instead of `@InputFile`/`@InputDirectory`; **missing `@PathSensitive`/normalization** on file inputs; an annotation on a private getter or a setter without a matching annotated getter; missing `@Nested` on a nested config object; and `@Internal` collisions. Each problem carries the offending type, property name, a description, and often a documentation link and a severity. With `failOnWarning`/`enableStricterValidation` these become errors. The fix is almost always adding or correcting the property annotation, or marking truly non-tracked state `@Internal`.

code

kotlin · 12 lines
kotlin
abstract class GenerateTask : DefaultTask() {
    @get:InputFile
    @get:PathSensitive(PathSensitivity.RELATIVE)
    abstract val template: RegularFileProperty

    @get:Input
    abstract val mode: Property<String>

    @get:OutputFile
    abstract val output: RegularFileProperty
}
// Each missing/incorrect annotation above would surface as a TypeValidationProblem.

go deeper

for a junior

Recognise that the most common problem is a property missing its input/output annotation.

for a middle

List the main categories and know the fix is to annotate correctly or mark @Internal.

for a senior

Explain each category's correctness/caching consequence and use @PathSensitive/@Nested appropriately under stricter validation.

for a principal

Drive consistent annotation conventions and validation gates across all org-authored task types.

## What a TypeValidationProblem is When `validatePlugins` (task type `ValidatePlugins`) analyses your types, every distinct issue it finds is modelled as a **`TypeValidationProblem`**. Each one identifies the *type*, the *property/member*, a human-readable *description*, typically a *documentation section* link, and a *severity*. The task aggregates them and either warns or fails. ## Major categories ### 1. Missing annotation A task getter that holds state but has no `@Input*`/`@Output*`/`@Internal`/`@Nested` annotation. Gradle cannot classify it, so it can't be tracked — the classic cause of incorrect up-to-date results. ### 2. Conflicting annotations Two incompatible annotations on the same property, e.g. `@Input` and `@OutputFile`, or `@InputFile` and `@InputDirectory`. The intent is ambiguous. ### 3. Wrong annotation for the type `@Input` on a `File`/`RegularFileProperty` — file inputs need `@InputFile`/`@InputDirectory` so Gradle reads *content*, not the path string. Reported as an incorrect-use problem. ### 4. Missing normalization / @PathSensitive Under stricter validation, a file input without `@PathSensitive` (or another normalization annotation) is flagged, because the default normalization is ambiguous and hurts caching/relocatability. ### 5. Structural issues Private getters annotated, setters without annotated getters, missing `@Nested` on a nested object that itself has tracked properties, or a getter that should be `@Internal` (e.g. a derived/transient value) but is left untyped. ## Example offender and fix ```kotlin abstract class GenerateTask : DefaultTask() { // PROBLEM: no annotation -> TypeValidationProblem @get:Internal // or @get:Input depending on intent abstract val mode: Property<String> @get:InputFile @get:PathSensitive(PathSensitivity.RELATIVE) abstract val template: RegularFileProperty @get:OutputFile abstract val output: RegularFileProperty } ``` ## Why each matters Every category maps to a correctness or performance consequence: untracked inputs cause stale outputs; missing outputs break caching; wrong file annotations break content tracking; missing path sensitivity breaks cache relocatability. That is why a published plugin should treat all `TypeValidationProblem`s as errors.

  • How do you legitimately silence a property that should not be tracked?
    Annotate it @Internal. That tells Gradle the property is intentionally not an input or output, which resolves the 'missing annotation' problem correctly.
  • Why is @Input on a RegularFileProperty a problem?
    @Input tracks the value itself (the path string), not file content. File inputs need @InputFile/@InputDirectory so Gradle hashes content and re-runs when the file changes.
  • What does a missing @Nested cause?
    A nested configuration object whose own properties are tracked won't have those properties seen as inputs unless the holder is @Nested, leading to missed input changes.

saying these in an interview costs you the question

  • Treating @Internal as a way to 'turn off the warning' for a property that really is an input — that hides a real bug.
  • Assuming @Input works for files.

context

resolving links…