7

I am using the dependency:analyze to detect dependency problems. But I have found a problem with the transitive dependencies because the plugin doesn't resolve this dependencies.

When I execute mvn dependency:tree, the output shows the transitive dependencies.

Dependencies

project A
  dependency B
project C
  dependency A

Outuput -> (project C - path)/ mvn clean install

[WARNING] Used undeclared dependencies found:
   dependency B: compile

Plugin

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <version>2.4</version>
    <executions>
        <execution>
            <id>analyze</id>
            <phase>verify</phase>
            <goals>
                <goal>analyze-only</goal>
            </goals>
            <configuration>
                <failOnWarning>true</failOnWarning>
            </configuration>
       </execution>
   </executions>
</plugin>

Why the plugin doesn't detect the transitive dependency

Sled
  • 18,541
  • 27
  • 119
  • 168
Javi Pedrera
  • 2,075
  • 4
  • 21
  • 29
  • Not really enough information here to answer your question. What did you expect the output to say? Which project did you run the analysis on? – Duncan Jones Jul 16 '13 at 19:53
  • I execute "mvn clean install" on Project C. If I put the failOnWarning option to false, the warning dissapears and the execution is OK. Why the plugin doesn't detect the transitive dependency – Javi Pedrera Jul 16 '13 at 20:00

1 Answers1

6

Dependency analysis works as expected.

Code in project C uses classes from project B but it does not directly depend on project B. It compiles only because it transitively depend on B through project A. Changing dependency of project A would break project C. This is what we are trying to avoid

This is not good, if the code uses classes from B, it should directly depend on B.

Grzegorz Żur
  • 47,257
  • 14
  • 109
  • 105
  • I need the Project A dependency because contains common libraries and code – Javi Pedrera Jul 16 '13 at 20:04
  • That is also fine, let C depend on A and B. – Grzegorz Żur Jul 16 '13 at 20:10
  • No, I shouldn't do this, and I am trying to work with transitive dependencies. – Javi Pedrera Jul 16 '13 at 20:13
  • Does your code in project A directly use code from project B? I mean importing classes. – Grzegorz Żur Jul 16 '13 at 20:16
  • Yes, In both projects, A and C, I need to import Project B classes – Javi Pedrera Jul 16 '13 at 20:18
  • 2
    So in this case, project C should directly depend on project B. That is the rule that dependency analyzer follows. If you don't follow that rule then changing dependency of project A would break project C. This is what we are trying to avoid. – Grzegorz Żur Jul 16 '13 at 20:20
  • 4
    @Grzegorz is right. A rule of thumb is to declare in your module's pom, all dependency directly used by your module's classes. Across a project life, refactoring can lead a dependency to disappear from a module. If other modules were relying on transitive dependencies to have the disappeared dependency in the classpath, this would lead to compilation failures. – Guillaume Darmont Jul 16 '13 at 20:28
  • Can you edit your answer to remove "Everything is fine"? Without a direct dependency on B, everything isn't fine. ;) – Barett Sep 28 '15 at 21:06