java maven 项目中的库版本冲突 [英] Conflicting library version in a java maven project

问题描述

在构建具有许多依赖项的 maven 项目时，其中一些依赖项依赖于相同的库，但使用不同的版本，这会导致在运行应用程序时出错.

When building a maven project that has many dependencies, some of those dependencies depend on the same library but use a different version which is causing errors when running an application.

例如，如果我添加两个不同的项目依赖项，A 和 B 都依赖于 apache commons http 客户端，但每个都在不同的版本上，一旦类加载器加载 A 的 apache commons http 客户端类，B 将尝试使用它们，因为它们已经被类加载器加载了.

For example, if I add two different project dependencies, A and B that both depend on apache commons http client but each one on a different version, once the class-loader loads A's apache commons http client classes, B will try to use them since they are already loaded by the class loader.

但是 B 的字节码取决于加载类的不同版本，导致在运行应用程序时出现多个问题.一个常见的方法是 methodnotfound 异常(因为 A 版本的 http 客户端不再使用特定方法).

But B's bytecode depends on a different version of the loaded classes causing multiple problems when running the application. A common one is methodnotfound exception ( since A's version of http client doesnt use a specific method anymore ).

在构建时避免此类冲突的一般策略是什么?是否必须手动检查依赖树才能找出哪些公共库相互冲突?

What is the general strategy when building to avoid such conflicts ? Does one have to manually check the dependency tree to figure out which common libraries colide with each other ?

推荐答案

欢迎使用 Maven 依赖地狱，众所周知.随着项目的增长和引入更多的外部依赖项，这是一个比较常见的问题.

Welcome to maven dependency hell, as it's fondly known. This is a somewhat common problem as projects grow and more external dependencies are introduced.

除了 Apache Commons(在您的原始问题中提到)之外，日志框架(log4j、slf4j)是另一个常见的罪魁祸首.

Besides Apache Commons (mentioned in your original question), logging frameworks (log4j, slf4j) are another frequent culprit.

我同意matts"给出的关于如何在确定冲突后解决冲突的建议.在早期捕获这些版本冲突方面，您还可以使用mavenenforcer"插件.请参阅 "dependencyConvergence" 配置.另见这篇SO帖子.

I agree with the advice given by "matts" on how to resolve conflicts once they are identified. In terms of catching these version conflicts early, you can also use the maven "enforcer" plugin. Refer to the "dependencyConvergence" config. Also see this SO post.

使用执行器插件会在版本冲突时立即使构建失败，从而避免手动检查.这是一种激进的策略，但可以防止引发您的问题/帖子的运行时问题类型.像任何东西一样，执行器插件有利有弊.我们在去年开始使用它，但后来发现它既是福也是祸.许多版本的库/框架是向后兼容的，因此(直接或间接)依赖于 1.2.3 和 1.2.4 版本在编译时和运行时通常都很好.但是，执行器插件会标记此冲突并要求您准确声明所需的版本.假设依赖冲突的数量很少，这不需要太多工作.然而，一旦你引入了一个大型框架(例如 Spring MVC)，它就会变得很糟糕.

Using the enforcer plugin will fail the build immediately on version conflict, which saves you from the manual checks. This is an aggressive strategy, but prevents the type of run-time problems that prompted your question/post. Like anything, the enforcer plugin has pros and cons. We started using it within the last year, but then discovered it can be a blessing and a curse. Many versions of libs/frameworks are backwards compatible, and so depending (whether directly or indirectly) on both version 1.2.3 and 1.2.4 is often fine at both compile-time and run-time. However, the enforcer plugin will flag this conflict and require you to declare exactly which version you want. Assuming the number of dependency-conflicts is small, this does not require much work. However, once you introduce a large framework (e.g. Spring MVC) it can get nasty.

希望这是有用的信息.

这篇关于java maven 项目中的库版本冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！