如果您正在开发一个大型不断发展的多模块 maven 项目，似乎不可避免地会在 pom 中给出一些不必要的依赖项，因为它们被其他依赖项传递包含。例如，如果您有一个最初包含 C 的模块 A，则会发生这种情况。后来您重构并让 A 依赖于模块 B，而该模块 B 又依赖于 C。如果您不够小心，您最终会同时包含 B 和 C A 的依赖列表。但是当然你不需要将 C 放入 A 的 pom 中，因为无论如何它都被传递地包含在内。是否有工具可以找到这种不必要的依赖项？
（这些依赖项实际上并没有受到伤害，但它们可能会掩盖您的实际模块结构，并且在 pom 中包含更少的东西通常会更好。:-)
在某种程度上您可以使用dependency:analyze，但它并没有太大帮助。还要检查JBoss Tattletale。
前段时间我已经启动了一个maven-storyteller-plugin以便能够更深入地分析 pom，但该项目离生产/公共使用还很远。您可以使用storyteller:recount目标来分析未使用/冗余的依赖项。
整个故事的问题是 - 如何确定“未使用”的东西。很可能分析的是实例类引用。但是，如果您使用反射 - 直接或非直接，它将不起作用。
2014 年 11 月更新。
我刚刚将 Storyteller 插件的旧代码移到了 GitHub 上。我会刷新它并发布到中央，以便其他人可以使用它。
我
个人使用 M2Eclipse 的 pom 编辑器来直观地查看依赖关系树（2D 树）。然后我看一下我的可交付（war，ear）lib 目录。然后仍然在 M2Eclipse pom 依赖项查看器中，我转到每个第 3 方，然后右键单击要排除的依赖项（在正确的依赖项中自动添加排除项）。
没有黄金法则，只是一些基本技巧：
很多 pom 是不正确的：很多 3rd 方库在默认编译范围内需要太多的依赖项，如果每个人都仔细制作他们的 pom，你一定不会有这么多不需要的依赖项。
您需要通过依赖项的名称来猜测您必须排除的内容，最好的例子是解析器、转换器、文档构建器：xalan、xerces、xalan alfred 和 co。尝试删除它们并使用内部 jdk1.6 解析器，常见的 apache 东西，log4j 也值得一看。
如果您没有不同版本的重复库，请定期查看 lib 交付（maven 的依赖解析器应该避免这种情况）
自下而上，从你的公共模块开始，然后上到服务层，减少每个模块的依赖关系，不要尝试从模块ear/war开始，太难了
经常检查您的交付物是否仍在工作，通过测试或比较旧交付物与新交付物（特别是在 web-inf/lib 目录中，winmerge/beyoncompare 消失的内容）
当你有A -> B, B -> C，然后重构A -> (B, C)。如果A仍然针对B进行编译，那么您非常不想简单地获取依赖项，因为您会传递地接收它。
想想A -> (B-1.0, C-1.0), B-1.0 -> C-1.0 的情况。一切都是同步的，因此为避免“重复”，您将C从A的依赖项中删除。然后升级 A 以使用B-2.0 -> C-2.0。您开始看到错误，因为A想要C-1.0类但找到了C-2.0类。虽然在这种情况下可以快速调和，但当您有很多依赖项时，情况就差得多了。
您非常希望A的 pom 中的信息表明它明确希望在类路径上找到C-1.0，以便您可以了解何时存在传递依赖冲突。同样，Maven 将确保任何特定 jar 的“最接近”版本最终出现在您的类路径中。但是当事情出错时——你想要你能得到的所有依赖元数据。
稍微实用一点，当您可以从 pom 中删除依赖项并且所有单元/集成/验收测试仍然通过时，该依赖项是未使用的。;-)