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