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

问题描述

在构建具有多个依赖关系的maven项目时，其中一些依赖关系取决于同一个库，但使用不同的版本，在运行应用程序时会导致错误。

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

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

构建以避免这种冲突的一般策略是什么？有人必须手动检查依赖关系树，找出哪些共同的库相互融合？

解决方案

欢迎来到 maven依赖地狱，因为它是知名的。除了Apache Commons（在你的原始问题中提到），日志框架（log4j，slf4j）还有一些常见的问题，因为项目的增长和更多的外部依赖关系被引入。另一个频繁的罪魁祸首。

我同意光纤提出的一旦确定冲突后如何解决冲突的建议。在提前捕获这些版本冲突方面，您还可以使用mavenenforcecer插件。请参阅dependencyConvergence配置。另请参阅此SO帖子。

使用强制插件会在版本冲突时立即失败，这样可以避免手动检查。这是一个积极的策略，但是阻止了引发您的问题/帖子的运行时问题的类型。像任何事情一样，执法者插件都有利弊。我们在过去的一年里开始使用它，但后来发现它可以是一种祝福和诅咒。很多版本的libs / framework都是向后兼容的，所以在版本1.2.3和1.2.4版本上，不管是直接还是间接，在编译时和运行时都是很好的。但是，执法者插件将会标记此冲突，并要求您正确声明所需的版本。假设依赖冲突的数量很少，这并不需要太多的工作。但是，一旦引入了一个大型的框架（例如Spring MVC），它可能会令人讨厌。

希望这是有用的信息。

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.

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.

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 ?

解决方案

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.

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

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.

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.

Hopefully that's useful information.

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