Maven 在美国是一个口语化的词语，代表专家、内行的意思。
Maven可以把你从上面的繁琐工作中解放出来，能帮你构建工程，管理jar包，编译代码，还能帮你自动运行单元测试，打包，生成报表，甚至能帮你部署项目，生成Web站点（Maven的一键构成）
Maven的优势举例
如果通过 Web 阶段项目，要能够将项目运行起来，就必须将该项目所依赖的一些 jar 包添加到工程中，否则项目就不能运行。试想如果具有相同架构的项目有十个，那么我们就需要将这一份jar包复制到十个不同的工程中。而WEB程序要运行，必须将项目运行所需的Jar包复制到工程目录中，从而导致了工程很大。同样的项目，如果我们使用Maven工程来构建，会发现总体上工程的大小会少很多（maven里面没有jar包）。
Maven的依赖管理
依赖管理：maven工程对jar包的管理过程
Maven 的一个核心特性就是依赖管理。当我们涉及到多模块的项目（包含成百个模块或者子项目），管理依赖就变成一项困难的任务。Maven 展示出了它对处理这种情形的高度控制。
传统的 WEB 项目中，我们必须将工程所依赖的 jar 包复制到工程中，导致了工程的变得很大。
而maven工程中不直接将jar包导入到工程中，而是通过在pom.xml文件中添加所需jar 包的坐标，这样就很好的避免了jar直接引入进来，在需要用到jar包的时候，只要查找 pom.xml文件，再通过pom.xml文件中的坐标，到一个专门用于”存放jar包的仓库”(maven仓库)中根据坐标从而找到这些jar包，再把这些jar包拿去运行。运行过程如图：
Maven仓库的分类
·本地仓库：用来存储从远程仓库或中央仓库下载的插件和jar包，项目使用一些插件或jar包，优先从本地仓库查找默认本地仓库位置在${user.home}/.m2/repository，${user.home}表示windows用户目录。
可以在MAVEN_HOME/conf/settings.xml文件中配置本地仓库位置：
<localRepository>放置jar包的文件夹路径</localRepository>
·远程仓库【私服】：如果本地需要插件或者jar包，本地仓库没有，默认去远程仓库下载。远程仓库可以在互联网内也可以在局域网内。远程仓库可以从本地上传jar包，也可以从中央仓库里下载。
·中央仓库：在maven软件中内置一个远程仓库地http://repo1.maven.org/maven2，它是中央仓库，服务于整个互联网，它是由 Maven 团队自己维护，里面存储了非常全的jar包，它包含了世界上大部分流行的开源项目构件。
·总结：
1. 在默认情况下启动一个maven工程会从本地仓库找jar包，如果本地没有，会从中央仓库中下载jar包。
2. 在公司中，启动一个maven工程，会从本地仓库找jar包，如果本地没有，回去私服（远程仓库）下载jar包。如果私服没有，可以从中央仓库下载，也可以从本地上传
镜像仓库配置
·在setting文件中配置阿里云镜像仓库
<mirrors>
<!--配置具体的仓库的下载镜像 -->
<mirror>
<!-- 此镜像的唯一标识符，用来区分不同的mirror元素-->
<id>nexus-aliyun</id>
<!-- 对哪种仓库进行镜像，简单说就是替代哪个仓库 -->
<mirrorOf>central</mirrorOf>
<!-- 镜像名称 -->
<name>Nexus aliyun</name>
<!-- 镜像URL -->
<url>http://maven.aliyun.com/nexus/content/groups/public</url>
</mirror>
</mirrors>
Maven的坐标
坐标：Maven中的坐标用于描述仓库中资源的位置
·Maven坐标主要组成
groupld：定义当前Maven项目隶属组织名称（通常是域名反写，例如：org.mybatis）
artifactld：定义当前Maven项目名称（通常是模块名称，例如CRM、SMS）
version：定义当前版本号
packaging：定义该项目的打包方式
·Maven坐标的作用
使用唯一标识，唯一性定位资源位置，通过该标识可以将资源的识别与下载工作交由给机器完成
Maven的使用
Maven目录文件说明：
bin:存放了maven的命令，如mvn tomcat:run
boot:存放了一些maven本身的引导程序，如类加载器等
conf:存放了maven的一些配置文件，如setting.xml文件
lib:存放了maven本身运行所需的一些jar包
Maven配置：
1. 在系统变量中配置MAVEN_HOME，变量值就是maven安装的路径（bin目录之前一级目录）
2. 在系统变量PATH中添加%MAVEN_HOME%\bin
·MAVEN运行需要依赖JAVA_HOME，因此需要确保JAVA_HOME的配置存在无误
3. 打开cmd窗口，输入mvn -v确认是否安装成功
Maven工程的目录结构：
src/main/java —— 存放项目的.java文件
src/main/resources —— 存放项目资源文件，如spring, hibernate配置文件
src/test/java —— 存放所有单元测试.java文件，如JUnit测试类
src/test/resources —— 测试资源文件
src/main/webapp —— 页面资源，js,css，图片等
target —— 项目输出位置，编译后的class文件会输出到此目录
pom.xml——maven项目核心配置文件
注意：如果是普通的java项目，那么就没有webapp目录。
Maven工程的运行：
在cmd窗口中进入maven工程目录（当前目录有pom.xml文件的位置），输入指令即可。
Maven常用命令：
mvn tomcat:run：启动tomcat服务器。该指令会启动tomcat服务器并自动生成该Maven工程同名的虚拟目录，输入该路径将访问项目中webapp中的默认html/jsp文件所生成的页面
mvn clean：maven工程的清理命令，执行clean会删除target目录及内容。
mvn compile：maven工程的编译命令，作用是将src/main/java下的文件编译为class文件输出到target目录下。
当接手一个项目一般会使用，因为之前开发时别人使用的jar包的版本、某些配置等等可能会与本机上的不同，因此需要删除掉此前的编译内容，再在本机中重新编译。
mvn test：maven工程的测试命令，执行src/test/java下的单元测试类。
当使用mvn test命令时，也同时会执行compile命令
mvn package：maven工程的打包命令，对于java工程执行package打成jar包，对于web工程打成wa包。打包后的文件放置在target目录中
可以通过pom.xml文件中的<packaging>标签来设定打包格式
mvn install：maven工程的安装命令，执行install将maven打成jar包或war包发布到本地仓库。
install命令首先会将compile、test、package全部执行，再将该maven发布到本地仓库中
Maven的生命周期：
maven 对项目构建过程分为三套相互独立的生命周期：
Clean Lifecycle（清理生命周期）在进行真正的构建之前进行一些清理工作。
mvn clean
Default Lifecycle（默认生命周期）构建的核心部分，编译，测试，打包，安装等等。 默认生命周期有一套规律：当执行后面的命令时，会先将前面的命令全部执行一次
compile -> test -> package -> install -> deploy（发布）
Site Lifecycle（站点生命周期）生成项目报告，站点，发布站点。
Maven的模型概念
Maven 是一个项目管理工具，它包含了一个项目对象模型 (POM：Project Object Model)，一组标准集合，一个项目生命周期(Project Lifecycle)，一个依赖管理系统(Dependency Management System)，和用来运行定义在生命周期阶段(phase)中插件(plugin)目标(goal)的逻辑。
l 项目对象模型 (Project Object Model)
一个maven工程都有一个pom.xml文件，项目对象模型包含了pom.xml文件中的项目自身信息、项目运行所依赖的jar包信息、项目运行环境信息（jdk、tomcat信息等）而项目运行所依赖的jar包信息又独立为一个依赖管理模型
l 依赖管理模型(Dependency Management System)
通过maven的依赖管理对项目所依赖的jar包进行统一管理。maven会根据pom.xml文件中配置的内容去central（中央仓库）、b2b（远程仓库）、local（本地仓库）中寻找该jar包
比如：
· 项目依赖junit4.9，通过在pom.xml中定义junit4.9的依赖即使用junit4.9，如下所示是junit4.9的依赖定义：
<!-- 依赖关系 -->
<dependencies>
<!-- 此项目运行使用 junit，所以此项目依赖 junit -->
<dependency>
<!-- junit 的项目名称 -->
<groupId>junit</groupId>
<!-- junit 的模块名称 -->
<artifactId>junit</artifactId>
<!-- junit 版本 -->
<version>4.9</version>
<!-- 依赖范围：单元测试时使用 junit -->
<scope>test</scope>
</dependency>
</dependencies>
在一个依赖管理模型<dependencies>中，其中标签<groupId>为公司组织的名称，<artifactId>为项目名，<version>为版本号。这几部分是不可或缺的，这几部分也就构成了一个依赖管理模型
项目安装插件tomcat7，通过在pom.xml中定义tomcat7的插件配置即使用tomcat7，如下所示是tomcat7的配置定义：
<build>
<!--设置插件-->
<plugins>
<!--具体的插件-->
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.1</version>
<!-- 配置插件的一些具体设置 -->
<configuration>
<port>80</port>
<path>/</path>
</configuration>
</plugin>
</plugins>
</build>
·pom文档最上方的一些标识定义：
<!--指定pom的模型版本-->
<modelVersion>4.0.0</modelVersion>
<!--打包方式，web工程打包为war，java工程打包为jar-->
<packaging>war</packaging>
<!--组织id-->
<groupId>com.itheima</groupId>
<!--项目id-->
<artifactId>web01</artifactId>
<!--版本号:release,snapshot-->
<version>1.0-SNAPSHOT</version>
l 一个项目生命周期(Project Lifecycle)
使用 maven 完成项目的构建，项目构建包括：清理、编译、测试、部署等过程，maven 将这些过程规范为一个生命周期
l 一组标准集合
maven 将整个项目管理过程定义一组标准，比如：通过maven构建工程有标准的目录结构，有标准的生命周期阶段、依赖管理有标准的坐标定义等。
l 插件(plugin)目标(goal)
maven 管理项目生命周期过程都是基于插件完成的。 每一个构建项目的命令都对应了一个maven底层的一个插件
依赖传递
· 依赖具有传递性
·直接依赖：在当前项目中通过依赖配置建立的依赖关系
·间接依赖：被依赖的资源如果依赖其他资源，当前项目间接依赖其他资源
依赖传递的冲突问题：
· 路径优先：当依赖中出现相同的资源时，层级越深，优先级越低，层级越浅，优先级越高
· 声明优先：当资源在相同层级被依赖时，配置顺序靠前的覆盖配置顺序靠后的
· 特殊声明：当同级配置了相同资源的不同版本，后配置的覆盖先配置的
可选依赖
可选依赖：对外隐藏当前所依赖的资源--不透明
操作：
<--! 在dependency中加入该配置 -->
<optional>true</optional>
排除依赖
排除依赖：主动断开依赖的资源，被排除的资源不需要指定版本
操作：
<--! 在dependency中加入该配置 -->
<exclusions>
<exclusion>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-core</artifactId>
</exclusion>
</exclusions>
依赖范围
依赖范围的传递性
