版本依赖解读

uap-build-4.1.1

uap-starter-4.0.2.snapshot

A和B都有依赖C两者的版本不一致导致了依赖冲突

D内有E但外层也有E而且版本不一致

uap-batch-starter-1.0.0.SNAPSHOT

父依赖parent

依赖C（2.0）

Caused by:java.lang.NoSuchMethodErrorCaused by: java.lang.ClassNotFoundException报错的时候很有可能是依赖冲突的问题，因为不能版本的jar可能添加或者删除了类或者方法不报错不代表没有依赖冲突，刚好没用到被删除的方法或者类也不会报错依赖冲突在编译的时候是无法发现的，因为编译的时候只是将java文件编译成了字节码，只有使用这个类的时候才会加载类才发现这个类不存在

uap-starter-4.0.1

spring-batch-core-4.2.1

业务项目使用方依赖的spring-batch-core最新版本的4.2.7都没有生效

mybatis1.0springboot2.2.4spring-batch-4.2.1

uap-log-starter-4.0.0

项目

依赖A

uap-log-4.0uap-monitor-4.1

spring-batch-core-4.2.4

uap-build-4.1.0

spring-batch-core-4.2.7

uap-log-4.1uap-monitor-4.2

依赖E（1.0）

uap-batch已经使用了最新的spring-batch-core-4.2.7版本

uap-starter-4.0.0

mybatis3.0springboot2.3.4json1.0spring-batch-4.2.4

依赖B

原因解读

uap-build-4.0

生效方法:1. 显示引用：项目使用方手动引入spring-batch-core-4.2.72.，在父依赖uap-starter-4.0.2.snapshot中引入spring-batch-core-4.2.7都可以生效(这个平台域改pom文件)

mybatis2.0springboot2.3.2spring-batch-4.2.4

解决方法：1、用<exclusion>标签去除冲突的jar包2、父工程中用<dependencyManagement>做版本锁定3、用idea插件maven Helper查找并解决

依赖D

业务使用方编译之后使用的spring-batch-core版本

依赖C（1.0）

maven同一个jar、包只会保留一个maven默认处理策略：1、最短路径优先      如图，D中有E，最外层也有E，外层E路径短，所以加载的是外层的E（1.0）2、最先声明优先      如图，A和B中C的路径在同一层，所以用最先声明，哪个在pom中先声明就用哪个。

依赖E（2.0）