为何JUnit自动依赖版本与pom定义不符？ClassNotFoundException问题咨询

你碰到的java.lang.ClassNotFoundException: org.junit.jupiter.api.MethodOrdererContext问题，根源就是JUnit相关依赖版本不兼容，而Maven依赖树里的版本和junit-jupiter-engine:5.4.0 pom中声明的版本对不上，核心是Maven的依赖调解机制在起作用，具体可以从这几个角度拆解：

1. 依赖传递的版本冲突与Maven调解规则 #

Maven默认靠两个规则解决版本冲突：最短路径优先和声明顺序优先。如果你的项目里还有其他依赖（比如某个第三方工具库、自定义的测试组件，甚至父pom里的依赖）已经声明了junit-platform-engine:1.3.2或junit-jupiter-api:5.3.2，而且这些依赖的传递路径比junit-jupiter-engine:5.4.0带来的路径更短，或者在你的pom里声明得更早，Maven就会选那个低版本。

举个例子：假设你项目依赖了一个叫foo-test-tools的库，而这个库直接依赖了junit-jupiter-api:5.3.2，那它的路径是你的项目 → foo-test-tools → junit-jupiter-api，和你的项目 → junit-jupiter-engine → junit-jupiter-api路径长度一样，这时候Maven就会选pom里先写的那个依赖版本。

2. 父POM的版本锁定可能"拖后腿" #

如果你的项目继承了父POM（比如公司内部的统一父pom、Spring Boot的starter parent这类），而父POM通过<dependencyManagement>块锁定了junit-platform-engine或junit-jupiter-api的版本为1.3.2/5.3.2，那Maven会直接用父POM锁的版本，完全忽略junit-jupiter-engine:5.4.0传递过来的版本要求。

<dependencyManagement>本来是用来统一管控版本、避免冲突的，但如果父POM的版本没跟上JUnit的更新，就会出现这种依赖版本不匹配的情况。

3. Maven 3.5.4的微小影响（非核心） #

Maven 3.x的依赖调解规则整体稳定，但不同小版本在处理一些边缘场景（比如多模块依赖传递、路径长度完全相同的冲突）时可能有细微差异。不过你用的3.5.4是比较成熟的版本，这个更多是辅助因素，核心还是前面两种情况。

验证方法 #

• 执行mvn dependency:tree -Dverbose，这个命令会详细显示每个依赖的来源，以及版本冲突时Maven选择版本的原因，能帮你定位到底是哪个依赖引入了低版本的JUnit组件。
• 检查项目的父POM或者自身的<dependencyManagement>块，看是否有锁定这两个依赖的版本。

补充说明 #

你用的显式声明版本的解决方法非常靠谱——直接在pom里指定junit-jupiter-api和junit-platform-engine为5.4.0，Maven会优先使用你显式声明的版本，覆盖传递过来的低版本。另外，也可以在项目的<dependencyManagement>里统一管理所有JUnit相关依赖的版本，这样整个项目（包括多模块）的版本都会保持一致，从根源避免这类问题。

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