使用多个版本号的多个 Maven 依赖项答案

【问题标题】：Multiple maven dependencies using multiple version numbers使用多个版本号的多个 Maven 依赖项
【发布时间】：2013-10-22 02:27:28
【问题描述】：

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

我们有一个公共库 (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 会期望/希望我们得到以下应用程序结构：

应用程序/

src/

目标/

lib-a/

core-1.1/

core-1.2/

虽然调试日志显示

core:zip:1.1:compile（已删除 - 较近找到：1.2）

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

【问题讨论】：

标签： javascript maven build-dependencies

【解决方案1】：

假设lib-a 包含一个方法m，它接受x 类型的参数，该参数在core 中定义。如果应用程序调用m，它将使用core-1.2 的x 类型版本，而m 方法旨在接收core-1.1 的x 类型版本。根据在core-1.1 和core-1.2 之间对x 的更改，这可能完全不兼容而无法工作。

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

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

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

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

【讨论】：

您好 Sander，感谢您的 cmets。欣赏您所说的话，并且会理解这在某些情况下可能会导致问题。然而，在我们的环境中，我们将使用别名来映射要针对应用程序和 lib-a 使用的 core-1.* 版本。这样在方法/参数调用中就不会有任何交叉。
不确定别名是什么意思？这是什么技术的概念？
我们实际上是在使用 Dojo，它允许我们设置路径别名，以便我们可以管理依赖关系。
这听起来好像你要使用core-1.1 构建lib-a，在文件系统中使用core-1.1 部署它，然后让它使用core-1.2（由于你如何设置aliases)。在我看来，您似乎不太可能避免我所描述的潜在冲突。如果 1.1 和 1.2 之间没有 API 更改，情况可能会稍微好一些，但由于您似乎将所有内容加载到同一个执行空间中，因此 1.1 和 1.2 似乎不太可能真正共存，所以您仍然会感到痛苦。
@SanderVerhagen 这里讨论的解决方案是使用 JavaScript 代码，当需要使用 dojo 的模块时，导入可以非常具体。因此，即使在同一个课程中，理论上您也可以使用多个版本的“核心”库！这就是复杂的地方，在您开始打包和构建之前，一切都是可能的，并且技术（在本例中为 Maven）为用户做出了一个预定的选择，不允许同一个库的多个版本。我通常会同意但在这种情况下不会同意的哲学。