mvn dependency:tree

Beginner·3 min read·

Fast recall

Quick revision

Core answer

The mvn dependency:tree command displays the full hierarchical tree of all dependencies—both direct and transitive—showing which library pulls in each dependency. You use it to diagnose version conflicts, find unwanted transitive deps, and understand your actual classpath composition.

Interview Answer3 min

The mvn dependency:tree command shows you the complete hierarchical tree of all dependencies in your project—both the ones you explicitly added to your pom.xml and all the transitive dependencies they pull in. It's the first tool you should reach for when debugging dependency issues. The output is structured like a family tree. Your direct dependencies are at the root level, then indented beneath each one you see all the transitive dependencies it brought in, then indented further you see their transitive dependencies, and so on. Each line shows the groupId, artifactId, version, and scope. This structure is critical because it tells you which dependency is responsible for each JAR on your classpath. Let's say you're getting a ClassNotFoundException for a Jackson class. You run dependency:tree and search the output for jackson-databind. The tree shows you it's coming from spring-boot-starter-web, which is three levels deep. Now you know where it's coming from and can decide if you need to exclude it or upgrade it. The command is also essential for debugging version conflicts. If two libraries depend on different versions of the same artifact, Maven has to pick one. The tree output shows you which version Maven selected and which it omitted, along with why—usually because of the nearest-wins rule. For large projects, the output can be hundreds of lines, so you use filters. The -Dincludes option lets you narrow down to a specific library. For example, mvn dependency:tree -Dincludes equals org.slf4j colon asterisk shows only SLF4J-related dependencies and the paths that brought them in. Another useful flag is -Dverbose, which shows even the dependencies Maven considered but didn't include, helping you understand conflict resolution. A common mistake freshers make is not knowing this command exists. They face a NoSuchMethodError or find an unexpected library on their classpath and start randomly changing versions in their pom, hoping to fix it. Always run dependency:tree first—it shows you the actual state of your classpath, which is often very different from what you think it is just by looking at your pom.

Interview-ready guide

Interview answer

xml and all the transitive dependencies they pull in.

It's the first tool you should reach for when debugging dependency issues. The output is structured like a family tree. Your direct dependencies are at the root level, then indented beneath each one you see all the transitive dependencies it brought in, then indented further you see their transitive dependencies, and so on.

Each line shows the groupId, artifactId, version, and scope. This structure is critical because it tells you which dependency is responsible for each JAR on your classpath. Let's say you're getting a ClassNotFoundException for a Jackson class.

You run dependency:tree and search the output for jackson-databind. The tree shows you it's coming from spring-boot-starter-web, which is three levels deep. Now you know where it's coming from and can decide if you need to exclude it or upgrade it.

The command is also essential for debugging version conflicts. If two libraries depend on different versions of the same artifact, Maven has to pick one. The tree output shows you which version Maven selected and which it omitted, along with why—usually because of the nearest-wins rule.

For large projects, the output can be hundreds of lines, so you use filters. The -Dincludes option lets you narrow down to a specific library. slf4j colon asterisk shows only SLF4J-related dependencies and the paths that brought them in.

Another useful flag is -Dverbose, which shows even the dependencies Maven considered but didn't include, helping you understand conflict resolution.

A common mistake freshers make is not knowing this command exists. They face a NoSuchMethodError or find an unexpected library on their classpath and start randomly changing versions in their pom, hoping to fix it. Always run dependency:tree first—it shows you the actual state of your classpath, which is often very different from what you think it is just by looking at your pom.

03 · Deep dive