假设您有一组使用各种版本的公共库（如Spring）的Web应用程序。我有一个业务逻辑库，也使用这个公共库。到目前为止没有任何问题，但是在此过程中，公共库的一个版本更改了抽象类定义并破坏了业务逻辑库。
所以我最终得到了一个看似这样的兼容版本表......
business-lib-version | common-lib-version
1.0 | 1.0
1.1 | 2.0
我不希望业务lib版本在使用应用程序中驱动公共lib版本。相反，我想基于公共库选择正确版本的业务库。我很确定这是不可能的，所以我继续讨论主要问题。
是否有一种优雅的方法来检测版本不兼容性？理想情况下，我想要一个构建时解决方案，否则早期的运行时解决方案就可以了。
我已经尝试在Maven中使用版本范围，但由于Maven如何对非标准版本格式的版本进行排序而导致我们遇到很多问题，并且在构建时正确解析范围时也存在各种问题。
答案 0 :(得分：4)
如果依赖版本被另一个依赖项意外阻止，则Ning dependency-versions-check Maven插件将无法构建。它不会为你修复它，但它至少会告诉你！
答案 1 :(得分：0)
我不知道有什么方法可以做到这一点 - 无论是在运行时还是在构建时。没有标准机制来确定包的版本而不调查清单或jar文件名 - 这最好是一个hack。也许有一个我不知道的maven插件是自动生成但我不知道。
我们只需修复我们的代码所需的库版本，并在需要时进行升级，因为我们需要其他功能或其他依赖项。通常我们领先于其他依赖项，因此我们在pom.xml中的依赖项定义中添加了一个典型的排除标记：
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>${spring-version}</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
这使我们可以依赖以后的版commons-logging。
但是，如果您使用的是1.0的库，但是其中一个依赖项使用的是2.0，则必须尝试exclusion并查看依赖项是否以1.0运行 - 甚至是编译。如果没有，那么您将被迫升级代码以使用2.0或降低依赖性。
很抱歉，我无法提供更多帮助。