你的项目会直接依赖一些项目，也可能会传递依赖一些项目；有的直接依赖，可能你本应该降格为传递依赖；有的传递依赖，你可能应该用作直接依赖；还有些直接依赖，可能你已经用不上应该去掉了。
mvn dependency:analyze就是用来帮你发现上述情况的一条命令。它会对两种情况作出警告：
1.
Used undeclared dependencies。 你的App的代码直接调用了B里的API，但当前B是通过App->A->B的关系被纳入到Classpath的。这种情况下，你应该将B升级为直接依赖。否则的话，如果A不再依赖Ｂ了，你依赖B的那些代码就会有编译错误，而且可能是很难找到原因的编译错误。
2.
Unused declared dependencies。你的App的代码没用直接调用B里的API，但却把B声明为App的直接依赖。 这种情况下，你要谨慎
a.App可能确实不需要直接依赖Ｂ，不过，可能会这样：App->A，A调用了Ｂ里的API，但A的pom里没有声明B。如果A的作者不负责任，这种情况就会出现，而且在大型组织里经常会遇到。这种情况下，你就要仍然把B留下来作为依赖，否则运行时A就会说找不到B而报错。
b.App的java代码里不需要直接依赖Ｂ，但是经过xml配置文件或者以反射方式调用了B里的API，这种情况下你也要保留B作为直接依赖。
c.App依赖了Ａ，Ａ依赖了Ｂ，这时你可以去除对Ｂ的直接依赖
d.App没有调用B里的代码，App的其他所有直接依赖和传递依赖的pom里都没有依赖Ｂ，也没有调用B里的API，这时也应该去除对B的直接依赖。 要判断App打包后是否需要B出现在classpath里，可以使用JarJar工具。它可以分析App打包后、包里所有的jar文件之间的java调用关系。