mvn dependency:tree fails on trivial project

Question

I've got a pretty complex project (about 100 modules) on which I'd like to run mvn dependency:tree. It fails, complaining about dependencies it cannot resolve. The project otherwise compiles fine. So I created the most basic project I could come up and it still fails with the same error. Obviously either I must be doing some very basic mistake or the maven-dependency-plugin has not been used by anyone yet. Here are the three POMs im by test project:

pom.xml:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>root</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>pom</packaging>
    <modules>
        <module>foo</module>
        <module>bar</module>
    </modules>
</project>

foo/pom.xml:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>foo</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>jar</packaging>
</project>

bar/pom.xml:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>bar</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>jar</packaging>
    <dependencies>
        <dependency>
            <groupId>com.example</groupId>
            <artifactId>foo</artifactId>
            <version>1.0.0-SNAPSHOT</version>
        </dependency>
    </dependencies>
</project>

Then I issue the following command mvn dependency:tree in the top-level directory and get the following output:

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO] 
[INFO] foo
[INFO] bar
[INFO] root
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building foo 1.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ foo ---
[INFO] com.example:foo:jar:1.0.0-SNAPSHOT
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building bar 1.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] foo ................................................ SUCCESS [  0.756 s]
[INFO] bar ................................................ FAILURE [  0.011 s]
[INFO] root ............................................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.065 s
[INFO] Finished at: 2015-03-03T16:19:18+01:00
[INFO] Final Memory: 13M/309M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project bar: Could not resolve dependencies for project com.example:bar:jar:1.0.0-SNAPSHOT: Could not find artifact com.example:foo:jar:1.0.0-SNAPSHOT -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :bar

What am I missing? Shouldn't this just work?

Did you run a mvn install first? If not, the foo module is not yet available in your repository and thus cannot be resolved in the bar module. — gizmo, Mar 03 '15 at 15:24
With this 3 pom.xml you gave the `mvn dependency:tree` works for me. As @gizmo said try to run `mvn clean install` first on the parent pom directory — Pierre, Mar 03 '15 at 15:27
@gizmo Should I? Wouldn't that put the artifacts into my global `.m2` directory? That seems like a very bad idea. I'm working on multiple branches of that project simultaneously and I don't want them to interfere. All the modules are in the project directory and listed in the top-level POMs `` tag. — Feuermurmel, Mar 03 '15 at 15:28
@jeanMarcAssin But then I would have to run `rm -r ~/.m2` in addition to each `mvn clean` which seems to me like a waste of bandwidth and time. — Feuermurmel, Mar 03 '15 at 15:30
@Feuermurmel It does not matter that they are referenced in the module tag of the top level pom. Using the `` tag make your parent pom act as a reactor module, form there, the order of computation can be deduced, but it does NOT remove the fact that the dependency resolution always works with the repository and not with the defined modules, hence the need for the `install` phase. — gizmo, Mar 03 '15 at 15:59
@jeanMarcAssin I actually meant `rm ~/.m2/repository`. The reason is that I want to get repeatable builds. I can't imagine how that works if I switch branches and artifacts from the previous branch are still in my local repository. And I'm not event starting to thing about building different versions of the project in parallel, all messing with my local repository. — Feuermurmel, Mar 03 '15 at 16:20
@gizmo But Maven does resolve the dependency when I run `mvn compile` (without running `mvn install`), how does that work then? — Feuermurmel, Mar 03 '15 at 16:21
"and artifacts from the previous branch are still in my local repository" isn't this the aim of the clean goal ? — Pierre, Mar 03 '15 at 22:48
@jeanMarcAssin AFAICT `mvn clean` does not remove those artifacts from my local repository. And it wouldn't solve the problem of two builds running in parallel. — Feuermurmel, Mar 04 '15 at 11:16
See related https://stackoverflow.com/questions/29712865/maven-cannot-resolve-dependency-for-module-in-same-multi-module-project/43200633#43200633 — tkruse, Jun 18 '18 at 07:40
Possible duplicate of [Maven cannot resolve dependency for module in same multi-module project](https://stackoverflow.com/questions/29712865/maven-cannot-resolve-dependency-for-module-in-same-multi-module-project) — tkruse, Jun 18 '18 at 07:40

William Leung · Accepted Answer · 2017-03-13T06:22:55.483

22

I'm frustrated why it didn't work.
A simple dependency analysis just didn't work.
And the official has no any guide how to do it.
Another much usefully command didn't work neither

mvn dependency:resolve

but, maybe you could try these commands instead

mvn test-compile dependency:resolve
mvn test-compile dependency:tree

anyway, it works for me

Update on Mar 13 2017

We can make it much more faster by skipping the compilation

 mvn test-compile dependency:resolve -Dmaven.main.skip=true -Dmaven.test.skip=true
 mvn test-compile dependency:tree    -Dmaven.main.skip=true -Dmaven.test.skip=true

So sad it didn't work for our project because our project was using kotlin, maybe it is kotlin's bug which didn't skip the compilation, maybe I should report this bug to jetbrains.

edited Mar 13 '17 at 06:22

answered Sep 19 '16 at 05:07

William Leung

1,556
17
26

I can't test this right now as I've long left the world of Java and Maven and replaced it with a completely different set of mindfucks. I'll accept this answer once someone else can confirm that it works. – Feuermurmel Sep 19 '16 at 09:18
@Feuermurmel it works because the `test-compile` LifeCycle could successfully resolve all dependencies (both main and test) project-locally, after that, the time while plugin task got execute, it could resolve the dependency successfully too, so lookup in repository would not be triggered, and no error occurs. It took more time to execute because it had to compile all the sources, but to me it is acceptable – William Leung Sep 19 '16 at 11:45
this works for me as well, thanks! the somewhat earlier lifecycle `compile` is working for me as well: `mvn compile dependency:tree` i think this should be a little quicker than running up to the `test-compile` lifecycle. – ribi86 Oct 05 '16 at 12:22
@ribi86 `compile dependency:tree` would fail if your multi-module project has `test-jar` dependency – William Leung Oct 06 '16 at 17:55
+1. This worked for my project. Executing "mvn dependency:tree" only failed miserably in the same way as OP, but executing "mvn test-compile dependency:tree" worked. @Feuermurmel - you should mark as accepted if you see this! – tonicsoft Mar 12 '17 at 15:12

score 10 · Answer 2 · answered Mar 04 '15 at 09:19

Ok, let's make a proper answer as the comments are a bit too short for a correct explanation.

Maven is a tool of various combined facets and it is sometime difficult to identify which parts are playing a role for a given command.

In your example, you have two classical projects, foo and bar and a special one, root.
root is special in the sense that it plays, in your example two roles.

The first one is called parent pom. It is usually used to fix the dependencies and plugins versions, as well as some common configuration that need to cascade to child projects. It has also a, sometime usefull, property in that the child projects inherit of the version unless explicitly specified in the child projects themselfs.
The second role is called reactor pom. This is the part mainly defined in the <modules> tag. It defines a set of other projects that to which a command can be sent as a group (e.g.: mvn clean install). When such command is executed, maven will look at the projects described in the <modules> and, based on their declared dependencies, will identify an order in which they have to called with the given command in order to maximize the chance of the build to succeed.

Now, about the behaviour of the various commands you tried (assuming they were all called on the root project:

mvn dependency:tree will perform a dependency analysis on all the project listed in the <modules> tag plus itself. This analysis is performed against the repository, meaning your local .m2 repo, and other external repository when needed. If you did not install your projects first in your repository, it will fail on bar as it cannot found com.example:foo:1.0.0-SNAPSHOT in there.
mvn [clean] install, using the same order, will perform a full packaging and deployment of your projects into your local repository. As bar will be executed after foo has been put into your repository, all will be fine and everybody will be happy.

But what abouth the mvn compile that works then?

Well, your case is a bit tricky. As your sample does not have actual code to compile, the dependency resolution for the compilation is skipped, and thus, no error occurs while your foo artifact is not available yet.

Now, about your remarks about branching and artifacts in your repo...
When you switch to a branch, unless all the other projects (modules) are using stable version number (i.e. without the SNAPSHOT suffix), you should perform a mvn [clean] install run on your reactor pom to ensure that you start working with a coherent set of modules and dependencies.
You might think that this is a waste of time, compared to e.g. interpreted languages, but it is the MAVEN way to handle projects. It ensures that all your modules are aligned before you start working.

First of all, tanks for the answer, but I'm not sure about two points: `com.example:root:1.0.0-SNAPSHOT` ist not the parent of the other two projects, I did not declare it as such in the modules `foo` and `bar`. And `mvn compile` _does_ work when the modules contain Java source code, even when the code in `bar` references the code in `foo`. — Feuermurmel, Mar 04 '15 at 11:40
About your remarks why I might see this as a waste of time. I'm not comparing it to other build systems like _GNU Make_, which of course solves a very different problem but does so without changing any global state and thus has, in my opinion, many advantages. It goes as far as that I can't see _why_ maven needs that global state, i.e. installing artifacts into the local repository so they can be used from other modules of the same project. — Feuermurmel, Mar 04 '15 at 11:42
It does not explain why the hack proposed in accepted answer works. `mvn test-compile dependency:tree -Dmaven.main.skip=true -Dmaven.test.skip=true` — JJ Roman, Jul 21 '21 at 19:44
yes, just running `mvn install` before `mvn dependency:tree` did the trick for me ;-) — user1767316, Feb 02 '22 at 09:32

score 1 · Answer 3 · answered Aug 19 '22 at 12:25

For me the issue came up attempting to enforce the requireUpperBoundDeps rule. I couldn't downgrade maven-enforcer-plugin (from 3.1.0 to 3.0.0-M3). I had to add exclusions to some dependencies

<dependency>
  <groupId>net.sf.ehcache</groupId>
  <artifactId>ehcache-core</artifactId>
  <version>${dep.ehcache}</version>
  <exclusions>
    <exclusion>
      <groupId>net.sf.ehcache</groupId>
      <artifactId>sizeof-agent</artifactId>
    </exclusion>
  </exclusions>
</dependency>
<dependency>
  <groupId>org.richfaces</groupId>
  <artifactId>richfaces</artifactId>
  <version>${dep.richfaces}</version>
  <exclusions>
    <exclusion>
      <groupId>jacorb</groupId>
      <artifactId>jacorb</artifactId>
    </exclusion>
    <exclusion>
      <groupId>org.richfaces.cdk</groupId>
      <artifactId>annotations</artifactId>
    </exclusion>
  </exclusions>
</dependency>
<dependency>
  <groupId>org.richfaces</groupId>
  <artifactId>richfaces-a4j</artifactId>
  <version>${dep.richfaces}</version>
  <exclusions>
    <exclusion>
      <groupId>jacorb</groupId>
      <artifactId>jacorb</artifactId>
    </exclusion>
    <exclusion>
      <groupId>org.richfaces.cdk</groupId>
      <artifactId>annotations</artifactId>
    </exclusion>
  </exclusions>
</dependency>
<dependency>
  <groupId>org.richfaces</groupId>
  <artifactId>richfaces-core</artifactId>
  <version>${dep.richfaces}</version>
  <exclusions>
    <exclusion>
      <groupId>jacorb</groupId>
      <artifactId>jacorb</artifactId>
    </exclusion>
    <exclusion>
      <groupId>org.richfaces.cdk</groupId>
      <artifactId>annotations</artifactId>
    </exclusion>
  </exclusions>
</dependency>

score 0 · Answer 4 · answered Jan 17 '22 at 16:59

0

I have the following error: java.lang.NoClassDefFoundError: org/sonatype/aether/*, but I solved using an older plugin, as indicated from the official page recalled by the error log:

mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:tree

answered Jan 17 '22 at 16:59

Alessandro Argentieri

2,901
3
32
62

score 0 · Answer 5 · answered May 16 '22 at 14:09

0

For me none of these worked. My maven-enforcer-plugin dependency version was set to 3.0.0 but changing it to 3.0.0-M3 did the trick for me.

answered May 16 '22 at 14:09

mr nooby noob

1,860
5
33
56

Im on 3.1.0, and I get an API incompatibility when I downgrade – caduceus Aug 19 '22 at 12:05

mvn dependency:tree fails on trivial project

pom.xml:

foo/pom.xml:

bar/pom.xml:

5 Answers5

Linked