一、Maven简介:
Maven是一个项目管理构建的工具，它涵盖项目的构建、依赖、测试、打包、部署、发布等等一系列的功能。并且Maven也成为了一个项目结构的标准。
因此现有的绝大部分IDE都将支持Maven项目。
二、安装：
1. 到Apache官网下载最新版本
2. 解压缩，并配置Maven的环境变量
3. 在Maven的核心配置文件settings.xml中配置本地仓库
<localRepository>D:/m2</localRepository>
三、仓库：
Maven仓库用于存放项目的jar文件以及Maven的插件，在开发的过程中所需要用的jar包，都可以从仓库中查找并依赖到当前项目中。
仓库分本地仓库和远程仓库
本地仓库顾名思义就是存在本机中的，maven在查找依赖的jar的时候先会从本地仓库查找，如果本地仓库没有则会访问远程仓库查找并下载到本地仓库中（Apache有一个庞大的远程仓库开发给所有开发人员使用。当然也有很多第三方的远程仓库）。当下一次再依赖相同的jar的时候，就可以从本地仓库找到，无需再访问远程仓库下载，节省网络带宽。
四、坐标（GAV）：
Maven在仓库中要找到具体的jar文件是通过坐标来查找的。
G代表的是组织，表示当前依赖的jar是隶属于哪个组织
A代表项目名，也就是jar的名称
V代表版本号，因为一个项目的jar是有多个版本，具体要依赖哪个版本
根据GAV坐标就能确定找到具体jar并依赖到当前项目中
在pom.xml文件中可以看到如下的配置：
<groupId>edu.hibenratedemo</groupId>
<artifactId>ch07</artifactId>
<version>1.0-SNAPSHOT</version>
五、pom.xml文件
pom的全程叫Project Object Module（项目对象模型）。每一个maven项目都有一个pom.xml文件，它是maven项目的核心配置。这个配置文件主要用于项目的坐标、依赖管理、项目属性、插件以及远程仓库的配置。
1.pom文件的依赖配置：
dependencies是依赖jar文件配置的根节点，根节点中可以配置多个dependencie依赖
每个dependencie依赖中指定的都是依赖的坐标，也就是我们所说的GAV。
例如：
<dependencies>
<!-- 添加hibernate依赖 -->
<dependency>
<!-- 组织名称 -->
<groupId>org.hibernate</groupId>
<!-- 项目名称-->
<artifactId>hibernate-core</artifactId>
<!-- 版本号-->
<version>5.2.11.Final</version>
</dependency>
<!-- 添加c3p0连接池依赖 -->
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-c3p0</artifactId>
<version>5.2.11.Final</version>
</dependency>
</dependencies>
2.关于<dependency>节点中的<scope>作用：
compile：
默认就是compile，什么都不配置也就是意味着compile。compile表示被依赖项目需要参与当前项目的编译，当然后续的测试，运行周期也参与其中，是一个比较强的依赖。打包的时候通常需要包含进去。
test
scope为test表示依赖项目仅仅参与测试相关的工作，包括测试代码的编译，执行。比较典型的如junit。
runntime
runntime表示被依赖项目无需参与项目的编译，不过后期的测试和运行周期需要其参与。与compile相比，跳过编译而已，说实话在终端的项目（非开源，企业内部系统）中，和compile区别不是很大。比较常见的如JSR×××的实现，对应的API jar是compile的，具体实现是runtime的，compile只需要知道接口就足够了。oracle jdbc驱动架包就是一个很好的例子，一般scope为runntime。另外runntime的依赖通常和optional搭配使用，optional为true。我可以用A实现，也可以用B实现。
provided
provided意味着打包的时候可以不用包进去，别的设施(Web Container)会提供。事实上该依赖理论上可以参与编译，测试，运行等周期。相当于compile，但是在打包阶段做了exclude的动作。
4.传递依赖
A->B->C->D
A如果依赖了B，而B又依赖了C和D，那么A就简介依赖了C和D，这就是传递依赖性。
依赖原则：
有时候通过maven的传递依赖也会导致重复依赖的现象。一旦发生这种情况，maven会根据
以下的原则顺序进行依赖
1. maven会优先依据最短路径原则来选择
2. 根据pom的配置的依赖顺序来选择
还可以通过排除的方式排除相同的依赖，在<exclusions>标签中配置即可
例如：
<dependency>
<groupId>org.evergreen</groupId>
<artifactId>evergreen-mvc</artifactId>
<version>1.2.1.RELEASE</version>
<!-- 排除依赖 -->
<exclusions>
<exclusion>
<groupId>org.javassist</groupId>
<artifactId>javassist</artifactId>
</exclusion>
</exclusions>
</dependency>
5.pom文件的属性配置：
properties节点用于配置maven项目的一些属性，比如项目的编码以及依赖jar的版本号统一设置。例如：
<properties>
<!-- 设置整个maven项目的编码格式 -->
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<!-- 配置控制台输出的编码格式，解决maven在控制台输出乱码 -->
<argLine>-Dfile.encoding=UTF-8</argLine>
<!-- 统一设置依赖jar的版本号,标签名可以自定义
通常都以"项目名.version""的方式命名-->
<hibernate.version>5.2.11.Final</hibernate.version>
<junit.version>4.12</junit.version>
<mysql.version>5.1.38</mysql.version>
</properties>
3.pom文件的插件配置:
maven本身的所有功能都是以插件的方式提供的。比如maven的依赖、编译、测试、打包、部署这些功能，都是有不同的插件模块完成，这些插件就构成了maven强大的功能。
我们也可以在pom文件中对这些插件进行相关的细节配置，例如配置编译插件的版本号，部署插件的部署设置等等。
例如：配置编译插件
<build>
<plugins>
<!-- 编译插件，指定JDK的编译版本为1.8 -->
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<target>1.8</target>
<source>1.8</source>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
</plugins>
</build>
六、Maven生命周期与插件：
Maven之所以强大，是因为它有一个十分完善的生命周期模型(lifecycle)。它拥有三套相互独立的生命周期，而每套生命周期都由一组阶段(Phase)组成。我们可以执行某个生命周期的某个阶段，也可以组合执行不同生命周期的不同阶段。(注意：执行了某个阶段，那么这个阶段之前的所有阶段都会执行),每个阶段的处理都由相应的插件来完成。
1. Clean 周期
说明：在进行真正的构建之前进行一些清理工作。
阶段：
pre-clean 执行一些需要在clean之前完成的工作
clean 移除所有上一次构建生成的文件
post-clean 执行一些需要在clean之后立刻完成的工作
2. Default 周期
说明：构建的核心部分，编译，测试，打包，部署等等。
阶段：
validate 验证项目是否正确且所有必要的信息都可用。
initialize 初始化构建工作，如：设置参数，创建目录等。
generate-sources 为包含在编译范围内的代码生成源代码。
process-sources 处理源代码。
generate-resources 生成资源文件。
process-resources 复制并处理资源文件，至目标目录，准备打包。
compile 编译项目的源代码。
process-classes 为编译生成的class文件做后期工作, 例如做Java类的字节码增强。
generate-test-sources 为编译内容生成测试源代码。
process-test-sources 处理测试源代码。
generate-test-resources 生成测试所需的资源文件。
process-test-resources 复制并处理资源文件，至目标测试目录。
test-compile 编译测试源代码。
process-test-classes 为编译生成测试的class文件做后期处理工作。
test 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。
prepare-package 执行打包前的预处理工作。
package 接受编译好的代码，打包成可发布的格式，如 JAR 。
pre-integration-test 预集成测试。
integration-test 按需求将发布包部署到运行测试环境。
post-integration-test 执行整合测试。
verify 执行后期校验。
install 将包安装至本地仓库，以让其它项目依赖。
deploy 将最终的包复制到远程的仓库，以让其它开发人员与项目共享。
3. Site 周期
说明：生成项目报告，站点，发布站点。
阶段：
pre-site 执行一些需要在生成站点文档之前完成的工作。
site 生成项目的站点文档。
post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备。
site-deploy 将生成的站点文档部署到特定的服务器上。