1. maven介绍
Maven 翻译为"专家"、“内行”，是 Apache 下的一个纯 Java 开发的开源项目。基于项目对象模型（缩写：POM）概念，
Maven 是一个项目管理工具，可以对 Java 项目进行构建、依赖管理。
Maven 下载地址：http://maven.apache.org/download.cgi
maven的安装依赖于java环境，需要先安装java环境。
2. maven生命周期
maven有三个标准的生命周期：
- clean：项目清理的处理
- default(或 build)：项目部署的处理
- site：项目站点文档创建的处理
每一个生命周期由许多阶段（phase）组成，如build生命周期主要有validate compile test package install deploy。
注意：
- 当一个阶段通过 Maven 命令调用时，例如 mvn package ，只有该阶段之前以及包括该阶段在内的所有阶段会被执行。
- 生命周期是相互独立的。如package是不包含clean的。
3. snapshot版本和release版本的区别
snapshot快照是一种特殊的版本，指定了某个当前的开发进度的副本。不同于常规的版本，Maven 每次构建都会在远程仓库中检查新的快照，Snapshot 版本代表不稳定、尚处于开发中的版本，Release 版本则代表稳定的版本。
什么情况下该用 SNAPSHOT?
协同开发时，如果 A 依赖构件 B，由于 B 会更新，B 应该使用 SNAPSHOT 来标识自己。这种做法的必要性可以反证如下：
a. 如果 B 不用 SNAPSHOT，而是每次更新后都使用一个稳定的版本，那版本号就会升得太快，每天一升甚至每个小时一升，这就是对版本号的滥用。
b.如果 B 不用 SNAPSHOT, 但一直使用一个单一的 Release 版本号，那当 B 更新后，A 可能并不会接收到更新。因为 A 所使用的 repository 一般不会频繁更新 release 版本的缓存（即本地 repository)，所以B以不换版本号的方式更新后，A在拿B时发现本地已有这个版本，就不会去远程Repository下载最新的 B
不用 Release 版本，在所有地方都用 SNAPSHOT 版本行不行？
不行。正式环境中不得使用 snapshot 版本的库。 比如说，今天你依赖某个 snapshot 版本的第三方库成功构建了自己的应用，明天再构建时可能就会失败，因为今晚第三方可能已经更新了它的 snapshot 库。你再次构建时，Maven 会去远程 repository 下载 snapshot 的最新版本，你构建时用的库就是新的 jar 文件了，这时正确性就很难保证了。
4. maven仓库
Maven 仓库有三种类型：
- 本地（local）
- 中央（central）
- 远程（remote）
本地仓库
Maven 的本地仓库，在安装 Maven 后并不会创建，它是在第一次执行 maven 命令的时候才被创建。运行 Maven 的时候，Maven 所需要的任何构件都是直接从本地仓库获取的。如果本地仓库没有，它会首先尝试从远程仓库下载构件至本地仓库，然后再使用本地仓库的构件。
默认情况下，不管Linux还是 Windows，每个用户在自己的用户目录下都有一个路径名为 .m2/respository/ 的仓库目录。Maven 本地仓库默认被创建在 %USER_HOME% 目录下。要修改默认位置，在 %M2_HOME%conf 目录中的 Maven 的 settings.xml 文件中定义另一个路径。
<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.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
<localRepository>C:/MyLocalRepository</localRepository>
</settings>
中央仓库镜像
Maven 仓库默认在国外， 国内使用难免很慢，我们可以更换为阿里云的仓库。
方法很简单，修改 maven 根目录下的 conf 文件夹中的 setting.xml 文件，在 mirrors 节点上，添加内容如下：
<mirrors>
<mirror>
<id>alimaven</id>
<name>aliyun maven</name>
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
<mirrorOf>central</mirrorOf>
</mirror>
</mirrors>
5. plugin插件
插件是maven的核心，所有的功能都有插件来提供。每个插件都有多个目标goal，每个goal是对插件功能的细分。
注意，插件的运行是需要绑定到生命周期的某一个阶段的。
6.maven命令
maven的命令有两种，一种是插件命令；一种是生命周期命令，他是maven为我们集成好的，多个插件命令的有序集合（也照应maven的功能都是由插件提供的），如mvn test ， mvn package等等，方便很常用。
7. 继承和聚合
- 依赖的范围
| compile | test | provided | |
|---|---|---|---|
| 编译 | √ | 不可以 | √ |
| 测试 | √ | √ | √ |
| 运行 | √ | 不可以 | 不可以 |
| 举例 | 依赖默认范围 | junit | servlet-api |
依赖原则：
1.路径最短优先原则。如果本工程就有，肯定用本工程的。
2.路径相同时：
如果在同一个pom文件中有两个相同的依赖（版本不同），后声明的会覆盖先声明的。但这种用法肯定是错误的。
如果在不同的pom文件，则依赖先声明的。即A依赖于B和C，B和C中分别有d1和d2依赖，则因为A中先声明依赖的B,所以A依赖的为d1.
- 聚合
利用maven开发时工程一般是多模块，利用聚合我们可以将多个模块聚合在一起：
<!--包含的子模块-->
<modules>
<module>cloud-api</module>
<module>cloud-common</module>
<module>cloud-web</module>
<module>cloud-view</module>
</modules>
这样我们只需要对父工程进行打包，子模块也跟着被打包。maven在打包子模块时会自动安排顺序，即会先打包其他再打包实际的web工程。
注意聚合工程的<packaging>pom</packaging>”，即必须为pom！
- 继承
继承主要是为了消除重复。父工程中除了artifactId和name，基本上所有的元素都可以被继承。父工程可以利用dependencyManagement来管理依赖版本。
聚合和继承在开发中经常作为同一个同时使用，但两者并无关系。聚合是为了方便同时打多个包，继承是为了消除重复。