skip to content

What does dependency:analyze do, and how do you act on its 'used undeclared' and 'unused declared' warnings?

level: middleimportance: should knowfreq 50%

answer

  1. bytecode scan vs declared
  2. used undeclared -> declare it
  3. unused declared -> maybe remove
  4. runtime-only deps fool it
  5. analyze-only / analyze-duplicate

basics

~10 s

mvn dependency:analyze byte-code-scans your classes to compare what you actually use against what you declare. It flags 'used but undeclared' (relied on transitively — should declare directly) and 'declared but unused' (candidates to remove).

solid answer

~40 s

The `analyze` goal of the `maven-dependency-plugin` inspects compiled bytecode to find which classes are actually referenced, then cross-checks against declared dependencies. It reports two problems. **Used undeclared**: you reference a type that comes in transitively — fragile, because if the intermediate dependency drops it, your build breaks; fix by declaring it directly. **Unused declared**: a dependency you list but never reference at compile time — a candidate for removal, though you must be careful: it may be needed at runtime only (reflection, SPI, JDBC drivers), which static analysis can't see. Run it with `mvn dependency:analyze`, or `analyze-only` after a build, and `dependency:analyze-duplicate` for duplicate declarations. It's commonly wired into CI via `analyze` with `failOnWarning=true`, but with explicit `ignoredDependencies` for known runtime-only artifacts.

code

bash · 1 line
bash
mvn dependency:analyze

go deeper

for a junior

Knows the goal flags undeclared-but-used and declared-but-unused dependencies.

for a middle

Understands the fix for each finding and that runtime-only deps cause false positives.

for a senior

Wires analyze into CI with curated ignore lists and weighs false-positive risk before removing.

for a principal

Sets org-wide dependency-hygiene policy balancing strictness against runtime/SPI false positives.

## The goal `mvn dependency:analyze` runs the `analyze` goal. It first ensures classes are compiled, then scans the bytecode to discover every type the project references, and compares that against the declared `<dependencies>`. ## The two findings - **Used undeclared dependencies**: classes you reference that are *not* declared directly — they arrive transitively. This is fragile: an upgrade of the intermediate library could remove the transitive jar and break your compile. **Fix: declare it directly** so your reliance is explicit and version-controlled. - **Unused declared dependencies**: declared dependencies whose classes you never reference at compile time. **Candidate for removal** — but only a candidate. Many are needed at **runtime** only and bytecode analysis cannot detect that: - JDBC drivers / `runtime` scope artifacts loaded via reflection - SPI/`ServiceLoader` providers - logging backends (e.g. logback bound to slf4j) - annotation processors used only at build time Removing a genuinely-needed runtime dependency yields `ClassNotFoundException` in production. ## Related goals - `dependency:analyze-only` — same analysis but assumes compilation already happened (faster in a build chain). - `dependency:analyze-duplicate` — finds the same dependency declared more than once. ## Wiring into CI ```xml <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-dependency-plugin</artifactId> <executions> <execution> <id>analyze</id> <goals><goal>analyze-only</goal></goals> <configuration> <failOnWarning>true</failOnWarning> <ignoredUnusedDeclaredDependencies> <dep>org.postgresql:postgresql</dep> </ignoredUnusedDeclaredDependencies> </configuration> </execution> </executions> </plugin> ``` This fails the build on undeclared usage while explicitly whitelisting runtime-only artifacts the analyzer can't see.

  • Why might 'unused declared' be a false positive?
    Bytecode analysis only sees compile-time references. Runtime-only deps loaded via reflection, ServiceLoader/SPI, JDBC drivers, or logging backends look unused but are required at runtime.
  • What's the risk of relying on a 'used undeclared' dependency?
    You depend on it only transitively; if the intermediate library drops or changes it, your compile breaks unexpectedly. Declaring it directly makes the dependency explicit and pins its version.

saying these in an interview costs you the question

  • Blindly deleting every 'unused declared' dependency
  • Claiming analyze can detect runtime/reflection usage
  • Ignoring 'used undeclared' as harmless

context

resolving links…