我正在尝试使用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会期望/希望我们得到以下应用程序结构：
应用程序/
的src /
目标/
LIB-A /
核 - 1.1 /
核 - 1.2 /
虽然调试日志显示
核心：zip：1.1：编译（删除 - 更近发现：1.2）
我理解它想在Java世界中这样做，有没有办法阻止它为我们的案例删除旧版本？
答案 0 :(得分：0)
想象一下，lib-a包含一个方法m，它接受x中定义的core类型的参数。如果应用程序调用{{1}}，则会使用m的{{1}}类型版本，而方法core-1.2旨在接收x的版本类型m。根据{{1}}和core-1.1之间的x的更改，这可能与不起作用完全不兼容。
你所描述的是Maven内部的共同斗争。我只能想象，如果没有Maven，斗争是一样的，因为这是你想要做的事情的固有问题。如果没有适当的依赖关系管理，结果可能实际上更加狡猾和微妙 - 即使Maven的几乎无声的调试日志语句也不太明确。 （不过，您可以在Maven生命周期中构建更强大的检查。）
有许多有用的开源库依赖于其他开源库，而这些库又反过来依赖自己，从而给你带来同样的问题，或至少同样的责任，以确保它们都使用相同的库或者确保它能够愉快地一起工作。
Maven允许您使用依赖项的“错误”版本（无论这意味着什么），但它不允许您使用相同依赖项的两个不同版本。
最重要的是，重新思考你在这里所做的事情，因为你要去焚烧。重新思考的一种方法可能是将x分开，以便在（当前调用的内容）core-1.1发生更改时，您（或更少）需要重新发布core-1.2这只是为了从属应用程序的利益。