我正在尝试使用带有 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会期望/希望我们得到以下应用程序结构：
应用程序/
源/
目标/
库-a/
核心-1.1/
核心-1.2/
虽然调试日志显示
核心：zip：1.1：编译（已删除 - 较近找到：1.2）
我知道它想在 Java 世界中这样做，有没有办法阻止它为我们的案例删除旧版本？
想象一下，它lib-a包含一个方法m，该方法x采用core. 如果应用程序调用m它将使用core-1.2类型的版本x，而该方法m旨在接收core-1.1类型的版本x。取决于对x之间的更改core-1.1，core-1.2这可能完全不兼容而无法正常工作。
您所描述的是 Maven 内部的常见斗争。我只能想象没有 Maven 的斗争是一样的，因为它是你想要做的事情的一个固有问题。如果没有适当的依赖管理，结果实际上可能更加隐秘和微妙——即使 Maven 几乎无声的调试日志语句也不是太明确。（不过，您可以在 Maven 生命周期中构建更强大的检查。）
有许多有用的开源库依赖于其他开源库，而你反过来也想依赖自己，因此给你同样的问题，或者至少有相同的责任来确保它们都使用相同的库或以其他方式使确保它可以愉快地协同工作。
Maven 允许您使用“错误”版本的依赖项（无论这意味着什么），但它不会让您使用同一依赖项的两个不同版本。
底线，重新考虑你在这里做什么，因为你正走向被烧毁。重新考虑的一种方法可能是拆分，core这样您就不需要（或不太频繁地）lib-a在（您当前所称的）core发生仅为依赖应用程序的利益而进行的更改时重新发布。