How to check dependency tree in maven

maven 2 - How to get a dependency tree for an artifact?


Modified 1 month ago

Viewed 448k times


New! Save questions or answers and organize your favorite content.
Learn more.

dependency:tree can be used to see the dependency tree for a given project. But what I need is to see the dependency tree for a 3rd party artifact.

I guess I can create an empty project, but I'm looking for something easier (I need to do this for several artifacts).

  • maven-2
  • build-process
  • dependencies


1) Use maven dependency plugin

Create a simple project with pom.xml only. Add your dependency and run:

mvn dependency:tree 

(Version for multi-module Maven project: mvn compile dependency:tree )

Unfortunately dependency mojo must use pom. xml or you get following error:

Cannot execute mojo: tree. It requires a project with an existing pom.xml, but the build is not using one.

2) Find

pom.xml of your artifact in maven central repository

Dependencies are described In pom.xml of your artifact. Find it using maven infrastructure.

Go to and enter your groupId and artifactId.

Or you can go to and navigate first using plugins groupId, later using artifactId and finally using its version.

For example see org.springframework:spring-core

3) Use maven dependency plugin against your artifact

Part of dependency artifact is a pom.xml. That specifies it's dependency. And you can execute mvn dependency:tree on this pom.


If you bother creating a sample project and adding your 3rd party dependency to that, then you can run the following in order to see the full hierarchy of the dependencies.

You can search for a specific artifact using this maven command:

mvn dependency:tree -Dverbose -Dincludes=[groupId]:[artifactId]:[type]:[version] 

According to the documentation:

where each pattern segment is optional and supports full and partial * wildcards. An empty pattern segment is treated as an implicit wildcard.

Imagine you are trying to find 'log4j-1.2-api' jar file among different modules of your project:

mvn dependency:tree -Dverbose -Dincludes=org.apache.logging.log4j:log4j-1.2-api 

more information can be found here.

Edit: The verbose flag has been reintroduced in version 3.2.0. You can use the specific version as below:

mvn org.apache.maven.plugins:maven-dependency-plugin:3.2.0:tree -Dverbose=true 


If anyone using IntelliJ wants to see dependency tree directly in IDE then they can install Maven Helper Plugin plugin.

Once installed open pom.xml and you would able to see Dependency Analyze tab like below. It also provides option to see dependency that is conflicted only and also as a tree structure.

If you use a current version of m2eclipse (which you should if you use eclipse and maven):

Select the menu entry

Navigate -> Open Maven POM

and enter the artifact you are looking for.

The pom will open in the pom editor, from which you can select the tab Dependency Hierarchy to view the dependency hierarchy (as the name suggests :-) )


When using IntelliJ, you have a one-click tool for Maven dependency exploration:



The for-artifact goal of the depgraph-maven-plugin should do what you want. To get a dependency graph of org. you simply do

mvn com.github.ferstl:depgraph-maven-plugin:3.3.0:for-artifact -DartifactId=jbossws-common-tools -Dversion=1.3.2.Final -DgraphFormat=text -DshowGroupIds=true -DshowVersions=true 

and you get +- +- org.apache.ant:ant:1.7.1:provided | \- org.apache.ant:ant-launcher:1.7.1:provided +- gnu.getopt:java-getopt:1.0.13:provided +- log4j:log4j:1.2.14:provided \- junit:junit:3.8.2:test 

without the need to create a Maven project or use and IDE or online app.

If your artifact is not a dependency of a given project, your best bet is to use a repository search engine. Many of them describes the dependencies of a given artifact.


Sign up or log in

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest


Required, but never shown

Post as a guest


Required, but never shown

java - How to find a dependency in maven, dependency:tree doesn't work


Modified 10 months ago

Viewed 2k times


New! Save questions or answers and organize your favorite content.
Learn more.

In a effective pom I see

<plugin> <artifactId>maven-site-plugin</artifactId> <version>3.3</version> <executions> <execution> <id>default-site</id> <phase>site</phase> <goals> <goal>site</goal> </goals> <configuration> <outputDirectory>/home/tatiana/repos/selenium-tests/masbuilder-tests/target/site</outputDirectory> <reportPlugins> <reportPlugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-project-info-reports-plugin</artifactId> </reportPlugin> </reportPlugins> </configuration> </execution> <execution> <id>default-deploy</id> <phase>site-deploy</phase> <goals> <goal>deploy</goal> </goals> <configuration> <outputDirectory>/home/tatiana/repos/selenium-tests/masbuilder-tests/target/site</outputDirectory> <reportPlugins> <reportPlugin> <groupId>org. apache.maven.plugins</groupId> <artifactId>maven-project-info-reports-plugin</artifactId> </reportPlugin> </reportPlugins> </configuration> </execution> </executions> <configuration> <outputDirectory>/home/tatiana/repos/selenium-tests/masbuilder-tests/target/site</outputDirectory> <reportPlugins> <reportPlugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-project-info-reports-plugin</artifactId> </reportPlugin> </reportPlugins> </configuration> </plugin> 

But I don't use maven-site-plugin and when I execute mvn dependency:tree

then I don't see any mention of maven-site-plugin or "site" keyword or maven-project-info-reports-plugin in output.

The same for mvn dependency:tree -Dverbose

The problem is error in effective POM which I would like to remove: element reportplugins is not allowed here

Maybe it is related with maven-surefire-plugin which I use?

  • java
  • maven
  • pom. xml
  • maven-surefire-plugin


If dependency is already present with the higher version in the tree, then all jruby-complete's dependencies are listed at shallower depth in tree, because dependency tree mojo prunes lower level dependencies.

You can use mvn dependency:tree -Dverbose=true to show the ommitted dependencies.


verbose might not work for Maven 3. There is also another solution from different question by using depgraph-maven-plugin:

mvn com.github.ferstl:depgraph-maven-plugin:3.3.0:graph -DrepeatTransitiveDependenciesInTextGraph -DshowVersions -DgraphFormat=text -DshowGroupIds -DshowConflicts -DshowDuplicates

Sign up or log in

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest


Required, but never shown

Post as a guest


Required, but never shown


Dependency Analysis / Habr

How to analyze dependencies in IDEA using the Dependency Structure Matrix and other tools.

This translation continues the IntelliJ IDEA series:

  • Best IntelliJ IDEA plugins
  • Compare files and folders
  • Dependency analysis

Dependency Matrix

This functionality is only available in IntelliJ IDEA Ultimate, not in the Community version.

IDEA provides a useful tool for analyzing internal dependencies in your project called the Dependency Structure Matrix. It can be used to analyze not only dependencies between packages, but also individual classes.

This can be very important, as closely related classes and modules, or even circular dependencies, means your code is very difficult to refactor and reuse.

The Dependency Structure Matrix, or DSM for short, can help you visualize your dependencies and find potential problems. First, be sure to run the build command on your project. Then, to start the analysis by going to menu " Analyze → Analyze Dependency Matrix... ". You need the IDEA Ultimate edition and include the included DSM Analysis Plugin .

After the analysis is completed, you will see something similar to this:

To better understand the matrix, look at the following screenshot.

IDEA omits column labels to save precious space, but behaves as if they were there.

Each row and column represents a package. Each cell represents the intersection of a row and a column - these are two packets. The number in the cell represents the number of dependencies one package has on another. This means that one class from the source package uses another class from the target package. The darker the cell, the more dependencies. If there are more than 99 dependencies, it shows ... instead of a number.

As long as the dependencies are blue, that's good, since they're only one-sided. Cyclic dependencies will be shown in red, which is not very good. But we'll see that later.

Visual Aid

The Matrix is ​​a powerful tool that can display a lot of information at the same time. However, it may be difficult to read at first if you are not used to working with it. Especially with hidden columns. Luckily, there is visual help that can help you better understand dependencies.

If you hover over a cell, it will show a tooltip indicating the direction of the dependency.

This may be helpful, but that's not all. You can click on any package on the left (not the individual cell with dependency numbers) and IDEA will show you some more useful information.

The row is highlighted in color, as well as the corresponding column representing the same package. Also, you can see that some other packages are highlighted in either yellow or green.

  • Packages on which the selected package depends are highlighted in yellow
  • Packages that depend on the selected package are marked in green

In addition to selecting the whole package, you can also click on individual cells. The color coding is the same, there is only one new concept. The purple cell represents the dependencies between the same two packages but in the other direction.

We need to go deeper

So far we have only worked at the package level. This is certainly useful, but often you need to go into great detail. This means that dependencies between individual classes must also be explored.

The DSM view is simple, you can expand your packages to see their contents. This way you can see dependencies for all potential subpackages or even individual classes.

Cyclic dependencies

So far, we've only covered unidirectional dependencies. But what you have to be very careful about is cyclic dependencies. In the DSM view they are marked in red:

You can see that class Owner has 15 dependencies on class Pet , while Pet has 5 dependencies on Owner .

Performing Actions

IDEA's DSM View is not only a useful tool for visualizing dependencies, but you can also perform many useful actions directly from the context menu by right-clicking a cell or package.

You can even refactor your classes directly from the DSM view. If you click on a cell with dependencies, you can call up the menu Find usages for dependencies . IDEA will look for all places in one of your classes/packages where another class/package is used.

Let's look at an example to be more specific. We can find all places in package service that use anything from package vet . Results classified by type:

Now you can check the entries one by one and see if you can improve your dependencies.

Maven dependency analysis

This functionality is only available in IntelliJ IDEA Ultimate, not in the Community version.

So far, we've only looked at internal dependencies in your own code. However, you may run into various issues, including external dependencies. These are third party libraries for your projects. This can be confusing because you don't only have direct dependencies, but your libraries have their own dependencies (transitive dependencies). You can run into many problems, such as conflicting versions of dependencies of the same artifact, or even circular dependencies. Maven prompts you to create a dependency tree view that can help you analyze potential problems. You can just call:

 mvn dependency:tree -Dverbose -DoutputFile=dependencies.txt 

Maven will output your dependency tree in text format, which might look something like this (here's the full example):

 com.vojtechruzicka:spring-boot-actuator-example: jar:1.0.0-SNAPSHOT +- org.springframework.boot:spring-boot-starter-actuator:jar:2.0.3.RELEASE:compile | +- org.springframework.boot:spring-boot-starter:jar:2.0.3.RELEASE:compile | | +- org.springframework.boot:spring-boot:jar:2. 0.3.RELEASE:compile | | +- org.springframework.boot:spring-boot-autoconfigure:jar:2.0.3.RELEASE:compile | | +- org.springframework.boot:spring-boot-starter-logging:jar:2.0.3.RELEASE:compile | | | +- ch.qos.logback:logback-classic:jar:1.2.3:compile | | | | \- ch.qos.logback:logback-core:jar:1.2.3:compile | | | +- org.apache.logging.log4j:log4j-to-slf4j:jar:2.10.0:compile | | | | \- org.apache.logging.log4j:log4j-api:jar:2.10.0:compile | | | \-org.slf4j:jul-to-slf4j:jar:1.7.25:compile | | +- javax.annotation:javax.annotation-api:jar:1.3.2:compile | | \- org.yaml:snakeyaml:jar:1.19:runtime 

In addition to plain text, various other formats are offered as output that are better suited for representing a dependency graph, such as graphml or tgf.

You can specify some other options to help you with your research, but for larger projects it can be difficult to work with the dependency tree output directly.

UPDATE : Be careful with the verbose option when using maven 3. x as it still uses the Maven 2 algorithm under the hood and may give you inconsistent results.

Fortunately, IDEA provides a nice GUI tool for working with Maven dependency graphs. This tool has been used in IntelliJ for a long time, but since version 2019.1 it has received some necessary improvements that make it much more useful in projects with large dependency graphs.

To show the graph, go to the pom.xml file and press Shift + Ctrl + Alt + U (or ⌥ + ⇧ + ⌘ + U on a Mac). Or right click -> Diagrams -> Show Dependencies .

You will see a scaled down dependency graph where it is not possible to see the individual element names unless you zoom in. Finding individual elements manually can be very painful. Luckily, you can use the command Find as usual using Ctrl + F .

Now we can easily identify a specific dependency, but still a lot of unrelated dependencies make it difficult to read the graph. Let's look at how to filter dependencies to get rid of unwanted noise.

The first option is to show only direct neighbors. That is, only direct dependencies of the current element, and only elements that directly depend on the selected element.

Note that this not only works for single items, but you can select multiple items by holding down the Shift button.

Another way to filter is to display a dependency chain leading from the root to the selected elements.

IDEA highlights conflicting dependencies in red for you. However, it can be hard to find if something is wrong in the huge dependency tree. Luckily, you can filter only the problematic parts:

In the example above, you can see the conflict between JUnit versions. There is an explicit dependency on JUnit 3.8.1 and another version transitively obtained via spring-boot-starter-test .

Maven Helper Plugin

If the graphical dependency tree is not what you need, there is an alternative for you. This is the Maven Helper plugin by Vojtech Krasa. It uses a hierarchical text representation of dependencies, similar to mvn dependency:tree , but with good dependency browsing capabilities.

This is also a good alternative if you are using IDEA Community Edition or using an older version of IDEA where the Maven dependency graph is useless.

To use the dependency analyzer offered by this plugin, simply open any pom.xml file. A new tab will appear at the bottom of your editor called Dependency Analyzer added by the editor.

In the left pane, you can view your dependencies (in list or tree view). The right pane shows how the selected dependency got into your application through the dependency chain. You can easily switch the view to show only conflicts.

Gradle dependency analysis

Starting with version 2019.2 , IDEA can finally show you a dependency diagram not only for Maven, but also for Gradle. Hooray! It works pretty much the same as the Maven dependency diagram.

Just go to the build.gradle file and press Shift + Ctrl + Alt + U (or ⌥ + ⇧ + ⌘ + U on Mac). Or right click → Diagrams → Show Dependencies .


When you're building an application, structuring your dependencies properly is important because an architecture with hard and messy dependencies can be very difficult to maintain, extend, and change. Luckily, IDEA can help with the Structured Dependency Matrix, which provides a useful graphical representation of your internal dependencies.

In addition to this, you must ensure that your external dependencies are also covered, which you can achieve by using the dependency graph for your dependency management system such as Maven.

Resolve dependency version conflicts when using the Azure SDK for Java

  • Article
  • Reading takes 6 minutes

This article describes dependency version conflicts and how to resolve them.

The Azure Client Libraries for Java depend on several popular third-party libraries: Jackson, Netty, Reactor, and SLF4J. Many Java applications and platforms use these libraries directly or transitively, resulting in version conflicts. Dependency managers such as Maven and Gradle resolve all dependencies in such a way that there is only one version of each dependency in a given classpath. But a resolved version of a dependency will not necessarily be compatible with all consumers of that dependency in the application. For more information, see the introduction to the dependency mechanism in the Maven documentation and the description of dependency resolution in the Gradle documentation.

Direct dependency API incompatibility results in compilation errors. Diamond dependency incompatibilities typically result in run-time failures such as NoClassDefFoundError, NoSuchMethodError, or other LinkageErrors. Not all libraries strictly follow semantic versioning, and there may be breaking changes in one major version.

Diagnosing version mismatch problems

The following sections describe methods for diagnosing version mismatch problems.

Using the Azure SDK for Java Build Tool

The Azure SDK for Java Build Tool, introduced at the AZURE SDK and Apache Maven Getting Started, helps you troubleshoot common issues. We recommend that you add this build tool to your project and run it by adding the target azure:run Maven object to your normal build process. With appropriate configuration, you can more proactively detect and resolve dependency conflicts before they become runtime problems.

View dependency tree

Run mvn dependency:tree or gradle dependencies --scan to display the complete dependency tree for the application (with version numbers). (Note that mvn dependency:tree -Dverbose provides additional information, but may be misleading. For more information, see the Apache Maven Dependency Tree section in the Maven documentation. ) For each library suspected of having a version conflict, write down the version number and determine which components depend on it.

Dependency resolution may work differently in development and production environments. Apache Spark, Apache Flink, Databricks, and IDE plugins require additional configuration for custom dependencies. They can also inject their own versions of Azure client libraries or shared components. For more information, see the following articles:

  • Application dependency pooling for Apache Spark
  • Project setup for Apache Flink
  • How to properly update the Maven library in Databricks for Databricks

For more information about resolving conflicts in these environments, see Creating a fat JAR later in this article.

Configuring Azure Functions

The internal dependency version for Azure Functions (only works on Java 8) takes precedence over the user-provided version. This dependency causes version conflicts, especially with Jackson, Netty, and Reactor.

To resolve this issue, set the environment variable FUNCTIONS_WORKER_JAVA_LOAD_APP_LIBS to true or 1 . Be sure to update the Azure Functions tools (version 2 or 3) to the latest version.


This configuration applies to Java 8-only Azure Functions. No special configuration is required for Functions with Java 11.

Configuring Apache Spark

The AZURE SDK for Java supports multiple versions of Jackson, but issues can sometimes occur depending on build tools and how dependencies are resolved. A good example of this is Apache Spark 3.0.0 (and later), which depends on Jackson 2.10. Although it is compatible with the AZURE SDK for Java, developers often find that a later version of Jackson is being used instead, resulting in incompatibilities. To fix this issue, pin a specific version of Jackson (compatible with Spark). For more information, see the "Multiple Versions of Jackson Support" section of this article.

If you are using earlier versions of Spark, or another library requires an even earlier version of Jackson that is not supported by the AZURE SDK for Java, continue reading this document for possible mitigation steps.

Jackson Runtime Version Detection

In Azure Core 1.21.0, we've added runtime detection and improved diagnostics of the Jackson runtime version.

If error 9 is displayed0251 LinkageError (or one of its subclasses) associated with the Jackson API, review the exception message and examine the runtime version information. Example: com/fasterxml/jackson/databind/cfg/MapperBuilder Package versions: jackson-annotations=2.9.0, jackson-core=2.9.0, jackson-databind=2.9 .0, jackson-dataformat-xml=2.9.0, jackson-datatype-jsr310=2.9.0, azure-core=1.19.0-beta.2

Review warning and error logs from JacksonVersion . For more information, see Set up logging in the Azure SDK for Java. For example: [main] ERROR - Version '2.9.0' of package 'jackson-core' is not supported (too old), please upgrade.


Make sure all Jackson packages are the same version.

For a list of packages used by the AZURE SDK and supported versions of Jackson, see Support for multiple versions of Jackson.

Troubleshooting version mismatches

The following sections describe how to troubleshoot version mismatches.

Using the Azure SDK specification

Use the latest stable Azure SDK specification and do not specify Azure SDK versions and dependencies in the POM file. If applicable, use the Azure Spring Boot specification.

The dependencies specified in the Azure SDK specification have been extensively tested to ensure there are no dependency conflicts.

Remove unnecessary dependencies

Remove dependencies if possible. Sometimes an application has dependencies on several libraries that provide almost the same functionality. These unnecessary dependencies can lead to vulnerabilities, version conflicts in the application, and increase support and maintenance costs.

Upgrading dependency versions

If migrating to the latest Azure SDK specification does not resolve the issue, identify the conflicting libraries and components that use them. (For more information, see "Viewing the dependency tree" earlier in this article.) Try updating to versions that protect against security vulnerabilities and often bring new features, performance improvements, and bug fixes.

We do not recommend downgrading the Azure SDK as it may introduce known vulnerabilities and issues to your application.

Shading Libraries

Sometimes it's impossible to find a combination of libraries that will work together, so you have to use shading.


Shadowing has significant disadvantages: it increases the package size and the number of classes in the classpath, makes code more difficult to navigate and debug, does not move JNI code, breaks reflection, and can also violate code licenses. It should only be used if other options are not possible.

Shading allows you to include dependencies in a JAR package at build time, which changes the package names and changes the application code to use the code in the shaded location. The conflict with the diamond dependency is no longer a problem, as there are two different copies of the dependency available. You can shade a library that has a conflicting transitive dependency or a direct application dependency, as described in the following list:

  • Transitive dependency conflict : For example, 3rd party library A requires Jackson 2.9, which is not supported by the Azure SDKs, and update A cannot be performed. Create a module that includes A and shadows (moves) Jackson 2.9 and (if needed) other A dependencies.
  • Application dependency conflict : The application uses Jackson 2.9 directly and can shade and move Jackson 2. 9 while working on a code updateinto a new module with the relocated Jackson classes.


Creating a "fat" JAR with relocated Jackson classes does not resolve the version conflict in these examples - it only results in a single shaded version of Jackson.

Building a fat JAR

Environments like Databricks or Apache Spark use custom dependency management and provide shared libraries like Jackson. To avoid conflicts with the provided libraries, you can create a "fat" JAR with all the dependencies. For more information, see the Apache Maven Shading Plugin page. In many cases moving Jackson classes ( com.fasterxml.jackson ) fixes the issue. Sometimes these environments also install their own version of the Azure SDKs, so you might decide to move the space names to avoid version conflicts.

Description of compatible dependency versions

For more information about dependencies for azure-core and their versions, see the azure-core page in the Maven Central Repository. The following table provides some general guidelines:

Dependency Versions supported
Jackson 2.10.0 and newer minor versions are compatible. For more information, see the "Support for multiple versions of Jackson" section.
SLF4J 1.7.*
netty-tcnative-boringssl-static 2.0.*
netty common 4.1.*
reactor core 3.X.* - The major and minor version numbers must exactly match the versions on which your version of azure-core depends. For more information, see the Project Reactor end-of-support policy.

Support for multiple versions of Jackson

The AZURE SDK for Java supports multiple versions of Jackson. The lowest supported version is Jackson 2.10.0. The Azure SDK for Java client libraries customize the configuration and use of Jackson based on the version found at runtime.

Learn more