介绍
maven：英文语义“专家”
作用：软件生命周期管理 （clean complie package install deploy）
我们平常使用：
1）jar包依赖管理
2）生命周期管理
配置文件
在maven主目录，conf目录下，有setting.xml文件：
maven仓库地址，默认是用户主目录/.m2/repository。这个文件是配置文件，跟你使用redis、kafka啥的有自己的配置文件是一个道理。
<!-- localRepository | The path to the local repository maven will use to store artifacts. | | Default: ${user.home}/.m2/repository <localRepository>/path/to/local/repo</localRepository> --> <localRepository>D:maven_repo</localRepository>
Idea创建maven项目并进行关联
archetype是选择一个骨架的意思，是maven项目会预先定义一个项目的初始内容结构。
这三个简称maven项目的坐标
然后下一步，设置项目名称和路径，finish即可。
建完maven项目底下有这个：
看下是否enable auto import , 当你改动了pom.xml的时候会自动更新包依赖。
idea项目配置maven工具
file-setting:
简单试下maven "package", "install"指令。打开idea terminal终端。
1、package: 顾名思义，打包。请注意这边默认是生成jar。
其实相当于pom.xml文件，<packaging>jar</packaging>这一行被省略了。
执行 mvn package， 会生成ArtifactId-Version.jar的一个文件。
2、install表示安装，会把当前生成的jar放到maven仓库。
执行maven install：
可以看到到仓库里面来了
用maven创建webapp，并定制骨架
选择骨架maven-archetype-webapp
可以看到这个骨架包含了web的相关目录，还往pom文件里面添加了一些依赖，我们可以在maven仓库中找到这个骨架的位置(大概就是我圈出来的路径)：
所以骨架其实也是一个项目，我们试着用360压缩双击打开，然后改点东西：
找到这里面的pom.xml文件，改点东西，如添加一个阿里的fastjson。
然后按上面的流程建一个web02的项目， 还是选择maven-archetype-webapp骨架：
可以看见依赖进来了。
所以我是想说明，maven项目初始的目录和依赖的配置哪里来，其实就是从一个jar的项目(这个项目就是我说的骨架)导进来的，可以在本地maven仓库找到，原本项目是在maven的中央仓库。如果手动改这个jar包，就相当于手动定制了这个骨架。
依赖的生命周期范围
compile: 缺省值(默认值，默认就是这个)，适用于所有的阶段(测试，编译，运行，打包)，会随着项目一起发布(被打包)。
provided：类似compile，期望jdk、容器或使用者会提供这个依赖。如servlet.jar参与测试，编译，不会被打包，这个包，tomcat里面有。
runtime:只在运行时使用，如jdbc6.jar，如驱动包，试用于运行和测试阶段，会被一起发布。就是说缺了这个，其实编译不会出错，但是跑起来会出问题。
test:只在测试的时候使用，用于编译和运行测试代码，如junut.jar，不会随项目发布。
system:Maven不会在Repository中查找它，要在本地磁盘目录中查找参与编译，测试，打包，运行。
阿里云仓库
在国内非常有必要了解下阿里云的仓库，这个速度快
配置如下，找到，你安装的maven的setting.xml文件：
<mirrors>
<mirror>
<id>alimaven</id>
<name>aliyun maven</name>
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
<mirrorOf>central</mirrorOf>
</mirror>
</mirrors>
id: 所配置的镜像的id，必须唯一。
name: 用户自己取的名称
mirrorOf: 仓库的id
url：一个路径
maven在找jar的时候，会先到本地找，如果找不到，会去你配置的这个远程仓库找。
maven的传递性
传递性就是项目依赖了A，但是如果A内部依赖了B，B也会被导入。很好理解，因为A也是一个项目，肯定也是有相关其他的依赖。
假如我打开maven项目，初始如下：
我现在引入依赖：
<dependency> <groupId>org.springframework</groupId> <artifactId>spring-context-support</artifactId> <version>4.3.6.RELEASE</version> </dependency>
好处: 简化依赖导入管理
缺点：可能引起jar包冲突
我再加一个依赖：
<dependency> <groupId>org.springframework</groupId> <artifactId>spring-context-support</artifactId> <version>4.3.6.RELEASE</version> </dependency> <dependency> <groupId>commons-beanutils</groupId> <artifactId>commons-beanutils</artifactId> <version>1.8.3</version> </dependency>
可以在右侧的maven选项查看下依赖路径：
现在变成commons-logging:1.1.1， 可以看到上一张截图其实是commons-logging:1.2。
maven默认选择的原则是最短路径：
(1)A->B->c.1.0
(2)A->c.2.0
maven将会选择(2)的那条路径。
那么问题来了，如果我就是要commons-logging:1.2呢？
有三个解决方案：
(1)排除原则
将commons-beanutils里面的commons-logging移除掉：
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context-support</artifactId>
<version>4.3.6.RELEASE</version>
</dependency>
<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
<version>1.8.3</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
变回了1.2.
（2）明确引用的版本
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context-support</artifactId>
<version>4.3.6.RELEASE</version>
</dependency>
<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
<version>1.8.3</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.2</version>
</dependency>
当前项目引用的是1.2，那根据最短路径原则，就会引用1.2，尽管现在没有加<exclusions></exclusions>。
（3）若有一个继承的关系，jar依赖会以父项目中的依赖或者版本为主。