Maven多项目依赖使用版本范围[0,)时旧版本被异常加载问题

问题原因 #

1. 开放式版本范围的传递依赖解析规则不符合预期 #

你在ApiUse中给Data_Types声明[0,)的版本范围，仅在直接构建ApiUse项目时，Maven才会主动扫描所有可用版本选择最新版。当ApiUse作为第三方依赖被引入其他项目时：

• Maven依赖调解优先遵循最短路径优先、声明顺序优先规则，不会优先选择版本范围对应的最新版：如果第三个项目的其他依赖、根pom的dependencyManagement中声明了固定版本的旧版Data_Types，且路径比ApiUse传递过来的更短、或声明顺序更早，Maven就会直接选用旧版，忽略[0,)的范围要求。你在依赖树中看到旧版的Data_Types条目，只是说明存在其他引入路径，并不是说Maven会把它加入类路径，仅代表冲突时的可选项。
• 即便没有其他显式声明，部分Maven版本对传递依赖的版本范围解析存在优化逻辑，会优先使用本地仓库中已经缓存的版本，而非每次都拉取最新的远程版本，也会导致旧版被选中。
• 你将版本改为固定0.1.10.1之后就恢复正常，是因为固定版本的传递依赖声明优先级和其他固定版本声明平等，只要路径/顺序占优就会被选用，不会出现版本范围解析的异常。

2. 多版本Jar冲突导致类加载异常 #

你遇到的「最终选择了最新版但方法还是从旧版加载」的问题，本质是classpath下存在多个版本的Data_Types Jar包：

• Maven的依赖调解只是决定依赖树中保留哪个版本的声明，但如果本地仓库、项目的类路径目录（比如WEB-INF/lib）中已经存在旧版的Jar包，类加载器会按照加载顺序优先加载先找到的类，旧版的类会覆盖新版的同名类，就会出现方法来自旧版的问题。
• Eclipse的本地依赖缓存也经常出现这类问题，依赖树显示正常，但实际构建的类路径下仍残留旧版Jar。

推荐解决方案 #

• 不要在正式发布的依赖中使用开放式版本范围[0,)：这种写法本身就会导致依赖版本不可控，建议要么声明固定版本，要么在根pom的dependencyManagement中统一管控所有公共依赖的版本。
• 如果一定要用版本范围，可在第三个项目的dependencyManagement中显式声明Data_Types的最新版本，该声明优先级最高，会覆盖所有传递依赖的版本。
• 出现类加载异常时，先执行mvn clean dependency:tree命令查看实际的依赖解析结果，再清理本地仓库对应Jar的缓存、清理Eclipse的项目构建缓存，确保类路径下只有一个版本的Data_Types Jar。

内容的提问来源于stack exchange，提问作者Skaros Ilias