The maven dependency tree shows all dependencies included in a project. This includes
primary dependencies, which are specified in the pom.xml, and also transitive dependencies,
which are used by the primary dependencies.
In the below example, Version 1 of Library D is used rather than Version 2, because it is closer
to the root project level.
The maven dependency tree of the above project, generated with -Dverbose, looks like this.
Notice that the package type, jar, is shown.
Supported package types are pom, jar, maven-plugin, ejb, war, ear, and rar.
To show the "resolved" dependency tree, only including files actually being used, run:
3. Maven Dependency Tree to File
A common thing you will want to do is export this to a file. This is easy and works on
mac, linux, and windows. For the remainder of this tutorial, I will show the commands
saving the results to a file.
mvn dependency:tree > depTreeFile
4. Show All Dependencies, Even Unused Ones
To show all dependencies, including conflicting dependencies that aren't used in the
resolved dependency tree, run:
mvn dependency:tree -Dverbose > depTreeFile.
Since only one version of any given library will
be used when building with maven, you can use the tree to see where different versions are being used,
and then you can pick which version you want by specifying it specifically as a dependency in the pom.xml.
In the above example, if you wanted to use version 2 of dependency D, you could specify it as a dependency
element inside the dependencies element. Then, dependency C and B would both use version 2 of dependency
Removing Third-Party Libraries with Vulnerabilities
Another use is to look for files with security vulnerabilities. As a software engineer, you are
not only responsible for writing secure code yourself, but also ensuring the third-party code
used in your project is safe. Explicit or transitive dependencies may use libaries which contain security vulnerabilities.
Using the dependency tree, you can identify whether such libraries are primary or transitive.
7. Four Ways to Remove a Dependency (to remove a Security Vulnerability, or conflict)
specifying a newer version of it - In the above example, if version 1 of dependency D has a security vulnerability, specifying version 2
as a dependency inside the dependencies element would ensure version 2 is used instead.
specifying a newer version of the parent - alternatively,
upgrading dependency B might bring in a newer version of dependency D.
excluding it - if dependencies B and C aren't
actually using dependency D, you can exclude dependency D from dependencies B and C to get rid of it.
removing the parent and rewriting the project source code - you could rewrite the code to not use dependencies A and B, which would get rid of