Maven中jar包冲突的解决方式

现象

建立一个maven工程，引入spring-context包。

<dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>5.0.8.RELEASE</version>
        </dependency>

此时看左侧的lib，咱们发现引入了一个坐标，多出了不少的jar包，这个现象叫作依赖传递，就是说，当前坐标所依赖的jar包也会一同引入进来，这里的版本都是5.0.8的。 接下来，咱们再引入一个springmvc。咱们换一个版本，咱们引入4.2.4版本

<dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-webmvc</artifactId>
            <version>4.2.4.RELEASE</version>
        </dependency>

咱们经过idea给的maven分析图能够看出，mvc和context都依赖与sprng-core一个，依赖的是5.0.8版本，一个依赖的是4.2.4版本。 那么真正加载的是哪一个版本呢。是5.0.8版本。 此时就是存在了jar包的冲突问题，那么咱们解决这个问题，有三种方式。

声明优先原则

此时咱们的pom文件中是先声明的5.0.8版本，后声明的4.2.4版本，咱们将其调换顺序。 此时咱们发现他们共同依赖的jar包，都变成了4.2.4版本，这就是声明优先原则。

就近优先原则

好比，咱们不想调换顺序，咱们就是想使用4.2.4版本的spring-core。咱们能够单独引入进来。 此时再看，咱们发现依赖的spring-core已经变成了4.2.4版本了。 这个就是就近优先原则，就近优先是直接依赖，直接依赖的优先级大于传递依赖的优先级。

排除依赖

这种方式咱们能够直接排除spring-context中的spring-core的传递依赖。 再看依赖，此时已经改成4.2.4. 使用exclusions标签的时候，其内部不用写版本号，这是惟一不用写版本号的一种状况。由于他默认就去找当前依赖的版本了。