Maven 配置与依赖冲突问题

Maven 是一个项目管理和整合工具。Maven 为开发者提供了一套完整的构建生命周期框架。开发团队几乎不用花多少时间就能够自动完成工程的基础构建配置，因为 Maven 使用了一个标准的目录结构和一个默认的构建生命周期。

在有多个开发团队环境的情况下，Maven 能够在很短的时间内使得每项工作都按照标准进行。因为大部分的工程配置操作都非常简单并且可复用，在创建报告、检查、构建和测试自动配置时，Maven 可以让开发者的工作变得更简单。

Maven 的主要目的是为开发者提供

一个可复用、可维护、更易理解的工程综合模型
与这个模型交互的插件或者工具
Maven 工程结构和内容被定义在一个 xml 文件中－ pom.xml

1.maven安装与配置

1.1 安装

Maven 是一个基于 Java 的工具，所以要做的第一件事情就是安装 JDK

Windows安装：maven下载地址，下载后解压，添加环境变量即ok。(将maven也加到环境变量的目的是在命令行的任意目录下，都可以使用“mvn”命令来操作）
Linux安装（Ubuntu）：

sudo apt-get update // 更新包索引
sudo apt-get install maven  // 安装maven
mvn -version // 校验maven是否安装成功

1.2 配置

将maven安装好后，文件目录如下：

bin目录:包含了maven运行的一些命令脚本
boot目录：包含的是类加载器的一些东西
conf目录：configuration配置的，保存一些配置文件的
lib目录：保存jar包的

在conf目录中，我们需要配置的就是settings.xml。settings.xml中一共有10个配置项，文件结构为：

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0http://maven.apache.org/xsd/settings-1.0.0.xsd"><localRepository/><interactiveMode/><usePluginRegistry/><offline/><pluginGroups/><servers/><mirrors/><proxies/><profiles/><activeProfiles/>
</settings>

localRepository：本地仓库位置
interactiveMode：标识maven是否需要和用户交互以获得输入。如果maven需要和用户交互以获得输入，那么则设置成true，不然则设置为false
offline：标识maven是否需要在离线模式下运行
pluginGroups：当插件的组织id(groupId)没有显示提供时，供搜寻插件组织Id的列表
servers：仓库的下载和部署是在pom.xml文件中进行定义的。比如说用户名，密码需要访问远程仓库的时候，有时候需要安全认证，这个认证就可以配置在servers标签中
mirrors：配置镜像所在的路径。默认的地址是国外的：https://repo.maven.apache…。maven要帮你管理jar，这些jar包下载的地址是从该地址下的，当然这个下载地址可以改变，就是通过mirrors标签。
proxies：用来配置不同的代理的
profiles：根据环境参数来调整构建配置的列表

虽然上线列举了这八项，但我们实际需要配置的，一般只有localRepository和mirros。

mirror：镜像仓库（远程仓库）

在maven构建项目的时候，它会帮我们把项目中所需要的一些基础的jar包下载下来，这个下载的地址就是由settings.xml文件里面的mirror标签所指定的。默认的地址是国外仓库：http://repo.maven.apache.org/maven2/。（注：2020年01月05日后，原来仓库的http协议已经不能使用，需要换成https协议）

由于国外镜像仓库速度慢，而且有被Q的风险。所以可以在mirrors里面配置上国内镜像仓库，建议使用国内的aliyun仓库，速度快。虽然阿里云快，但官方的镜像仓库还要配上，因为一些依赖阿里云镜像仓库可能没有（如新版本jar包）

其实无论是myeclipse还是idea里面都集成了maven，默认安装了maven。所以在使用idea时一定要手动设置成本地的maven，并设置setting.xml位置（因为本地找不到时，会通过xml的配置去私服和远程仓库去找）

localRepository：本地仓库

localRepository配置的是本地仓库，存放所有下载下来的jar包。项目下载依赖前会先在本地查找，如果有了，那么就不会再次去重复下载，从而节约本地的存储空间。注意，这个jar包版本一定是要一致的才算有了，如果版本不一致，不能算作有，比如mysql的5.1和5.6。

再强调一次，本地仓库与maven一般不在一个目录，本地仓库需在setting.xml中配置。

2.maven初体验

maven主要是做什么的？答：打jar、war包和管理jar包。下面就演示一下Java原生命令打jar包和使用maven打jar包，大家可以看看区别。

2.1 Java命令打包

假如我们有一个Main.java文件，想要将它打成可执行jar包，一般这样做：

使用javac命令对要打包的java文件进行编译

这里一般使用javac -d . xxx.java，因为直接javac会生成class在当前目录，而-d会生成package的目录（如下图，如果直接javac就直接在com.xupt.yzh下生成class文件，而如果javac -d.就会在com.xupt.yzh包中又生成了一个com.xupt.yzh包）。

那又生成一个com.xupt.yzh包又有什么用呢？将要打包的文件(.class)与源文件(.java）隔离。参考链接…
编写META-INF/MANIFEST.MF文件，写入口类版本等信息
执行打包，jar -cvfm MF文件目录打包文件目录。生成文件在src目录下：
运行jar包，由于是在src目录下，直接运行java -jar xxx.jar即可

2.2 maven打包

1.在pom文件内配置入口类

2.执行maven打包命令 mvn package，生成jar在target目录下

3.运行生成的jar，结果与原始方式无区别

可以看到，相较于原始的打包方式，maven帮我们做了太多的简化。

3.maven项目构建

约定优于配置 (Convention Over Configuration)。要去使用maven帮你进行jar包的管理，以及项目的构建和管理等等，你就要遵循maven的规定/约定。maven要求的你的工程结构必须是哪样哪样的。MyEclipse/IDEA 中想怎么建就怎么建，这边放这个，这边放那个。有了maven之后，你就不能那么随心所欲的。

3.1 maven项目目录结构

项目目录结构，实际上指的是maven要求你的项目必须的一个目录层次。

统一入口，所有配置在一个pom里搞定！pom文件的结构如下：

这里说以下两点：

maven只能单继承，即一个项目只能使用parent标签定一个父级项目。使用dependencyManagement并设置其scope=import，即表示继承此项目为父项目

dependencyManagement是声明而不引入依赖--------因此子项目需要显式的声明需要用的依赖（不需要版本号）。当子项目中引用一个依赖而无版本号时，会沿着父子层次向上走，直到找到一个拥有dependencyManagement元素的项目，使用其版本号。

pom文件更详细的配置信息可以参考这篇…

3.2 maven解析过程

当我们执行 Maven 构建命令时，Maven 开始按照以下顺序查找依赖的库：

Maven版本：

version（SNAPSHOT）：快照版本。随时更新不稳定的，每个版本都只是特定时间点的快照。同时，SNAPSHOT的不稳定性会带来风险，本地仓库中快照版本的依赖的目录下会看到带有时间戳的jar包。
例如：A–>B-1.3.8-SNAPSHOT（理解为A依赖了B的1.3.8-SNAPSHOT版本），那么B-1.3.8-SNAPSHOT更新且重新deploy到仓库之后，A只需要重新构建就可以拿到最新的代码，不用修改依赖B的版本。这样达到了变更传达的透明性。

version（RELEASE)：发布（正式）版本，是稳定的版本号，应该一旦发布永远不变。

version（LATEST）：不稳定版本，不管是快照还是发布版，就是去拉最新的。

注意，不推荐直接使用<version>RELEASE<version> 和 <version>LATEST<version>，因为它们都会在打包时去远程仓库拉取最新的，从而可能导致同一项目在打包时依赖不同的jar包。

依赖是具体的发布版本（xxx.RELEASE）:

在本地仓库中搜索，找到则成功。
在远程仓库中搜索，找到则下载。
如果没有设置远程仓库，Maven 默认去中央仓库搜索，找到则下载。
在一个或多个远程仓库中搜索依赖的文件，如果找到则下载到本地仓库以备将来引用，否则 Maven 将停止处理并抛出错误（无法找到依赖的文件）。

依赖是快照版本（xxx.SNAPSHOT、RELEASE、LATEST）：

基于更新策略更新（updatePolicy= always），则总是尝试去远程仓库拉取最新版本
强制快照更新------mvn clean install-U

4.maven坐标与依赖

4.1 坐标

在数学中, 任何一个坐标可以唯一确定一个“点”。Maven 中坐标是Jar包的唯一标识，坐标元素包括groupId、artifactId、version、packaging:

元素	描述	说明
groupId	定义当前模块隶属的实际Maven项目	中小企业常常直接对应公司/组织
artifactId	定义实际项目中的一个Maven模块	唯一标识一个模块
version	定义当前项目所处版本	SNAPSHOT 表示不稳定的版本。 LATEST 指最新发布的版本，可能是个发布版，也可能是一个snapshot版。 RELEASE 指最后一个发布版。
packaging	定义Maven项目打包方式	有jar(默认)、war、pom、maven-plugin等.
classifier	附属构件(如javadoc、sources)	须有附加插件的帮助
scope	依赖范围	具体见下面依赖部分

4.2 依赖

依赖即：A -->B，B–>C，C–>D这种项目间的依存关系。在java的jvm内，依赖的最终表现是，项目A启动时，其依赖的jar包必须都对应放入其classpath路径内。

1.依赖范围（scope）

mvn在运行时，生命周期的不同阶段，会有不同的依赖范围，一般有以下依赖范围scope

compile ：默认范围，编译范围，编译和打包都会依赖
provided：提供范围，编译时依赖，但不会打包进去。如：servlet-api.jar
runtime: 运行时范围，打包时依赖，编译不会。如：mysql-connector-java.jar
test: 测试范围，编译运行测试用例依赖，不会打包进去。如：junit.jar
system: 需要外在提供相应的元素。通过systemPath来取得 ----- 一般禁止使用

每个scope实际上是配置了一个不同的classpath，jvm根据选择不同的classpath来达到依赖不同

注：profile，一般在mvc项目中根据配置运行环境与测试环境代码等

2.依赖传递

即一个项目A依赖项目B，项目B又依赖项目C，因此各个项目间的依赖也会进行传递

上述过程中，项目Mall归结起来，依赖的fastjson会有三个版本。而我们的jvm最终肯定只能接受一个版本的jar，所以必须有所取舍。

maven默认的取舍规则是：

路径最短原则：product和customer里的fastjson引用路径较短，路径为两步 ;pay项目里的fastjson引用路径较长，路径为三步。因此pay中的fastjson被淘汰
同路径长度下，谁先声明谁优先： product和customer中的fastjson路径相同，那么就看在pom中是先声明product还是先声明customer，谁先用谁的

3.依赖冲突及解决

在依赖传递里，我们看到，maven根据自己的规则为我们取舍出了一个版本的jar，但此jar版本选择可能会与我们的项目预期不符。

比如，我们最终想的版本是fastjson:1.2.30版本-----但它在第一步即被淘汰掉了，所以我们项目运行可能会出错（项目中使用到了1.2.30版本的特性）。此问题即是我们常遇到的jar包冲突问题

补救方式：

当发生jar冲突程序报错时，可以使用mvn命令查出项目最终依赖的jar包树，看版本是否是我们预期的：
使用exclusions将product和customer中的fastjson包排除掉，用法如下图：