When AI Generates Code, How to Eliminate Zombie Dependencies with Maven

In recent projects the operations team often requests dependency upgrades because of reported vulnerabilities, but the real pain point is oversized packages and slow compilation caused by hidden transitive dependencies.

Why Maven Dependency Management Is Mandatory

For Java applications, managing dependencies is no longer optional. The maven-dependency-plugin is the most fundamental tool for this task, acting as a precise "surgical knife" that reveals the full dependency tree.

According to recent OWASP Software Composition Analysis reports,

92% of Java applications contain at least one vulnerable third‑party dependency

, and 38% of those have high‑severity issues. Many of these vulnerabilities come from transitive dependencies that are not declared directly in pom.xml.

Three Commands That Solve 80% of Dependency Problems

dependency:tree

This is the most common command. When a security alert points to a vulnerable library that you cannot find in pom.xml, mvn dependency:tree lets you trace the exact path of inclusion.

# Show the full dependency tree
mvn dependency:tree

# Filter for a specific artifact (e.g., log4j‑core)
mvn dependency:tree -Dincludes=org.apache.logging.log4j:log4j-core

# Debug mode for detailed resolution
mvn dependency:tree -Dincludes=org.springframework:spring-web -X

Example: an old project reports spring-web:5.3.13 as vulnerable (CVE‑2022‑22947). The command reveals that the vulnerability is introduced via spring-boot-starter-web, allowing a targeted version bump or a dependencyManagement override.

dependency:analyze

Long‑lived projects accumulate "zombie" dependencies that are never used, increasing build time and attack surface. mvn dependency:analyze lists such unused declarations.

# Analyze unused dependencies
mvn dependency:analyze

Sample output shows org.apache.commons:commons-lang3:3.12.0 as declared but not referenced. Running this regularly in CI/CD, together with dependency:analyze-dep-mgt, keeps pom.xml tidy.

copy-dependencies (and build‑classpath)

When you need to copy resolved JARs to a directory or generate a classpath file for scripts, Docker images, or class‑loader debugging, the copy-dependencies goal does the job.

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-dependency-plugin</artifactId>
  <version>3.6.1</version>
  <executions>
    <execution>
      <id>copy-dependencies</id>
      <phase>package</phase>
      <goals>
        <goal>copy-dependencies</goal>
      </goals>
      <configuration>
        <outputDirectory>${project.build.directory}/lib</outputDirectory>
        <includeScope>runtime</includeScope>
      </configuration>
    </execution>
  </executions>
</plugin>

Typical Use Cases

Precise fixing of transitive vulnerabilities: Identify the exact path of a vulnerable artifact and decide whether upgrading the direct dependency or excluding the transitive one is feasible.

Version conflict arbitration: Resolve ClassNotFoundException or NoSuchMethodError by locating conflicting versions with dependency:tree and analyze-duplicate.

Build consistency across teams: Use dependency:resolve and dependency:go-offline to pre‑download all artifacts, avoiding "works on my machine" issues.

Collaboration with vulnerability scanners: Although the plugin does not scan for CVEs, it provides the visibility required by tools like OWASP Dependency‑Check or Snyk to complete the "detect → locate → fix" loop.

Conclusion

The maven-dependency-plugin is not a silver bullet; it does not tell you which dependency is vulnerable. However, it gives you the ability to see the full dependency structure, which is crucial in an era of frequent software‑supply‑chain attacks such as the 2024 MavenGate incident. By moving from passive remediation to proactive defense—regularly visualizing, analyzing, and cleaning dependencies—you build a more secure and efficient Java ecosystem.