使用多个版本号的多个 maven 依赖项

Multiple maven dependencies using multiple version numbers

本文关键字：依赖 maven 版本号      更新时间：2023-09-26

我正在尝试使用Maven和JavaScript应用程序进行原型设计。然而，我们的用例让我想知道我们需要的东西是否真的可行。

我们有一个公共库 （lib-a），它依赖于其 POM 中指定的核心库 （core-1.1） 的 1.1 版。然后，我们有一个使用 lib-a 的应用程序，但使用核心库的 1.2 版。lib-a 仍然需要使用 1.1，因为它是一个经过测试/发布/批准的库，我们很高兴它是稳定的，目前不需要重新发布。

在我们的应用程序POM中，我们引用lib-a和core-1.2;然后调用mvn clean verify期望/希望我们得到以下应用程序结构：

.app/

来源/

目标/

lib-a/

核心-1.1/

核心-1.2/

虽然调试日志显示

核心：zip：1.1：编译（已删除 - 接近找到：1.2）

我知道它希望在 Java 世界中这样做，有没有办法阻止它为我们的情况删除旧版本？

假设lib-a包含一个方法m，该方法采用 core 中定义的类型 x 的参数。如果应用程序调用m它将使用core-1.2 的 x 类型版本，而方法m设计为接收core-1.1 版本的类型 x。根据core-1.1和core-1.2之间x的变化，这可能足够不兼容，无法正常工作。

你描述的是Maven内部的共同斗争。我只能想象，如果没有Maven，斗争是一样的，因为这是你想要做的事情的固有问题。如果没有适当的依赖管理，结果实际上可能会更加狡猾和微妙 - 即使Maven几乎无声的调试日志语句也不太明确。（不过，您可以在Maven生命周期中构建更强大的检查。

有许多有用的开源库依赖于

其他开源库，而你反过来也想依赖你自己，因此给你同样的问题，或者至少是相同的责任，以确保它们都使用相同的库或以其他方式确保它愉快地一起工作。

Maven 允许您使用依赖项的"错误"版本（无论这意味着什么），但它不会让您使用同一依赖项的两个不同版本。

底线，重新考虑你在这里做什么，因为你即将被烧伤。重新考虑的一种方法可能是拆分core这样您就不需要（或更少）在对（您当前称为）core进行更改时重新发布lib-a，这些更改只是为了依赖应用程序的利益。

相关文章：