skip to content

What are static analysis plugins in Maven, and how do you make one (e.g. Checkstyle) actually run during your build?

level: juniorimportance: must knowfreq 55%

answer

  1. plugin + execution + phase + goal
  2. check goal fails, report goal doesn't
  3. verify in CI
  4. configLocation / rules file
  5. SpotBugs needs bytecode

basics

~20 s

Static analysis plugins inspect source/bytecode for style and bug issues without running it. You add the plugin to your pom and bind its check goal to a build phase (often verify) inside an <execution> so mvn verify runs it automatically.

solid answer

~30 s

Static analysis tools (Checkstyle, PMD, SpotBugs, Spotless) examine code without executing it to catch style violations, bugs, and security smells. In Maven you add the plugin under <build><plugins>, then add an <execution> with an <id>, a <phase> (commonly verify), and the <goal> to run (e.g. checkstyle:check, pmd:check, spotbugs:check, spotless:check). The bare *:check goals fail the build on violations; the analyze/report goals only produce reports. Binding to a phase means a normal mvn verify enforces the rules in CI, so nobody has to remember to run the tool manually. You typically also point the plugin at a config/rules file and configure failOnViolation/failsOnError.

code

xml · 5 lines
xml
<execution>
  <id>checkstyle-validate</id>
  <phase>verify</phase>
  <goals><goal>check</goal></goals>
</execution>

go deeper

for a junior

Add the plugin, bind its check goal to a phase, run mvn verify.

for a middle

Knows check vs report goals, configLocation, failOnViolation, and that SpotBugs needs bytecode.

for a senior

Chooses phases for fast feedback vs completeness and wires the gate into CI deliberately.

for a principal

Standardizes the tool set and bindings across all repos via a parent/BOM so enforcement is consistent org-wide.

## What is static analysis? Static analysis means inspecting code *without running it* to find problems: formatting/style issues, likely bugs, anti-patterns, and security smells. It contrasts with dynamic analysis (unit tests, profilers) which run the program. In a Maven project these tools are delivered as **plugins**. ## The Maven plugins in this space - **maven-checkstyle-plugin** — enforces coding *style* (naming, imports, braces, Javadoc) from a Checkstyle ruleset XML. - **maven-pmd-plugin** — finds *code smells / likely bugs* from source (unused vars, empty catch, complexity) and also runs CPD (copy-paste detector). - **spotbugs-maven-plugin** — analyzes *bytecode* for bug patterns; plug in **find-sec-bugs** for security findings. - **spotless-maven-plugin** — a *formatter*; can auto-fix (spotless:apply) or just verify (spotless:check). - **error-prone** — not a standalone Maven plugin; it hooks into javac as a compiler plugin via maven-compiler-plugin, catching bugs at compile time. ## Report goal vs check goal Each tool usually has two kinds of goals: - a *report/analyze* goal (e.g. `checkstyle:checkstyle`, `pmd:pmd`, `spotbugs:spotbugs`) that produces an HTML/XML report and does **not** fail the build; - a *check* goal (e.g. `checkstyle:check`, `pmd:check`, `spotbugs:check`, `spotless:check`) that **fails** the build when violations exist. ## Binding to a phase Maven runs **goals** during lifecycle **phases**. To enforce a tool automatically you bind its check goal to a phase using an `<execution>`: ```xml <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-checkstyle-plugin</artifactId> <version>3.6.0</version> <configuration> <configLocation>config/checkstyle.xml</configLocation> <failOnViolation>true</failOnViolation> <consoleOutput>true</consoleOutput> <violationSeverity>warning</violationSeverity> </configuration> <executions> <execution> <id>checkstyle-validate</id> <phase>verify</phase> <goals><goal>check</goal></goals> </execution> </executions> </plugin> ``` Now `mvn verify` runs Checkstyle and fails on violations — perfect for CI gates. People debate `validate` (very early, fast feedback) vs `verify` (after tests). Style/format checks are cheap so `validate` gives fast failure; bytecode tools like SpotBugs need compiled classes so they bind around `compile`/`verify`.

  • Why bind to verify instead of just running checkstyle:check manually?
    Binding makes it run on every build/CI without anyone remembering, so violations gate merges automatically rather than relying on developer discipline.
  • Which of these tools needs compiled classes rather than source?
    SpotBugs analyzes bytecode, so it must run after compilation; Checkstyle and PMD work on source.

saying these in an interview costs you the question

  • Confusing the report goal (checkstyle:checkstyle) with the failing check goal (checkstyle:check)
  • Thinking adding the plugin alone enforces rules — without an <execution> bound to a phase it only runs when invoked by hand

context

resolving links…