12

如果您正在开发一个大型不断发展的多模块 maven 项目,似乎不可避免地会在 pom 中给出一些不必要的依赖项,因为它们被其他依赖项传递包含。例如,如果您有一个最初包含 C 的模块 A,则会发生这种情况。后来您重构并让 A 依赖于模块 B,而该模块 B 又依赖于 C。如果您不够小心,您最终会同时包含 B 和 C A 的依赖列表。但是当然你不需要将 C 放入 A 的 pom 中,因为无论如何它都被传递地包含在内。是否有工具可以找到这种不必要的依赖项?

(这些依赖项实际上并没有受到伤害,但它们可能会掩盖您的实际模块结构,并且在 pom 中包含更少的东西通常会更好。:-)

4

3 回答 3

13

在某种程度上您可以使用dependency:analyze,但它并没有太大帮助。还要检查JBoss Tattletale

前段时间我已经启动了一个maven-storyteller-plugin以便能够更深入地分析 pom,但该项目离生产/公共使用还很远。您可以使用storyteller:recount目标来分析未使用/冗余的依赖项。

整个故事的问题是 - 如何确定“未使用”的东西。很可能分析的是实例类引用。但是,如果您使用反射 - 直接或非直接,它将不起作用。

2014 年 11 月更新。

我刚刚将 Storyteller 插件的旧代码移到了 GitHub 上。我会刷新它并发布到中央,以便其他人可以使用它。

于 2010-03-31T15:32:19.437 回答
2

个人使用 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 消失的内容)

于 2010-04-08T20:36:22.760 回答
1

当你有A -> B, B -> C,然后重构A -> (B, C)如果A仍然针对B进行编译,那么您非常不想简单地获取依赖项,因为您会传递地接收它。

想想A -> (B-1.0, C-1.0), B-1.0 -> C-1.0 的情况。一切都是同步的,因此为避免“重复”,您将CA的依赖项中删除。然后升级 A 以使用B-2.0 -> C-2.0。您开始看到错误,因为A想要C-1.0类但找到了C-2.0类。虽然在这种情况下可以快速调和,但当您有很多依赖项时,情况就差得多了。

您非常希望A的 pom 中的信息表明它明确希望在类路径上找到C-1.0,以便您可以了解何时存在传递依赖冲突。同样,Maven 将确保任何特定 jar 的“最接近”版本最终出现在您的类路径中。但是当事情出错时——你想要你能得到的所有依赖元数据。

稍微实用一点,当您可以从 pom 中删除依赖项并且所有单元/集成/验收测试仍然通过时,该依赖项是未使用的。;-)

于 2010-03-31T16:40:07.293 回答