pomtool, a fast Maven pom.xml analyzer

mvn tooling can take multiple seconds, pomtool tree is almost instant.

$ pomtool tree --format mvn
[INFO] com.example:myapp:jar:1.0.0
[INFO] +- org.springframework.boot:spring-boot-starter-web:jar:3.5.6:compile
[INFO] |  +- org.springframework.boot:spring-boot-starter-json:jar:3.5.6:compile
[INFO] |  |  +- com.fasterxml.jackson.core:jackson-databind:jar:2.19.2:compile
...

---

Why this exists

Five reasons pomtool exists:

1. Avoid JVM cold start.
2. Maven is self-hosting: every Maven tool is a Maven plugin written in Java. I don’t know any external tooling in Go because the people using Maven write Java, not Go.
3. Dependency resolution is hard: parent POM inheritance, BOMs, dependencyManagement, property interpolation, mirrorOf wildcard matching. It’s complex, and I’m not sure if I got everything right, but it’s functional.
4. Support for settings.xml layer: pomtool tries to support it for those of us blocked in a corporate world with proxies and internal nexus.
5. No existing tool works offline: pomtool resolves entirely from your local .m2 cache; network is only needed for cache misses, and disabled if --offline.
6. pomtool why and pomtool where: help quickly diagnosing why a dependency is there, and from where it comes (works also with properties).
7. pomtool lint: is quick enough that it can be called by an IDE plugin (that needs to be written).
8. pomtool vuln: find vulnerabilities in your pom, and which dependency brought it.
9. pomtool search: find artifacts on the web, from the terminal.

I know, it’s more than 5.

Real reason why

I am a daily Java developer, and I have been working primarily on large enterprise-grade projects for years.

In many corporate environments (especially with managed machines) standard Maven commands can be slow to execute, particularly on large multi-module projects. This becomes even more problematic in CI pipelines, where diagnosing dependency issues quickly is critical but often time-consuming.

I started developing pomtool to address this gap. I wanted a fast, lightweight alternative that provides immediate insight into Maven dependency graphs. By significantly improving performance, it enables workflows that are impractical with traditional tooling, such as real-time linting (pomtool lint), rapid vulnerability inspection (pomtool vuln), and exploration of dependency trees (pomtool tree / pomtool deps).

Another key motivation was clarity, in fact in complex builds, it is often challenging to understand why a dependency is present (pomtool why), which path introduced it, or how its version is being managed (pomtool where). pomtool is designed to make these relationships explicit and easy to trace, reducing the time spent debugging dependency issues.

The project is intended to evolve further, with plans for an LSP server to integrate these insights directly into IDEs (when I am some more spare time), enabling instant feedback during development.

Features

• tree: replaces mvn dependency:tree with a faster, more readable output.
• deps: flat dependency list.
• outdated: find outdated dependencies
• diff: dependency changes between two versions
• bom-diff: compare two BOM versions
• conflicts: version conflicts
• why: why is this dep in my build?
• where: where is this defined?
• search: search an artifact from your terminal
• vuln: find vulnerabilities in your dependencies
• licenses: license inspection
• policy: enforce dependency rules in CI
• lint: static analysis for POM files
• diagnose: corporate environment debug tool
• It is benchmarked against dependency:tree and dependency:list with both mvn and mvnd on real Spring Boot projects and libraries.

Until next time!