一、Maven简介

 Maven这个单词的本意是：专家，内行。读音是['meɪv(ə)n]或['mevn]，不要读作“妈文”。简单来说：Maven是一款自动化构建工具，专注服务于Java平台的项目构建和依赖管理。

什么是构建？

 构建就是以我们编写的Java代码、框架配置文件、国际化等其他资源文件、JSP页面和图片等静态资源作为“原材料”，去“生产”出一个可以运行的项目的过程。

构建环节

1) 清理：删除以前的编译结果，为重新编译做好准备。
2) 编译：将Java源程序编译为字节码文件。
3) 测试：针对项目中的关键点进行测试，确保项目在迭代开发过程中关键点的正确性。
4) 报告：在每一次测试后以标准的格式记录和展示测试结果。
5) 打包：将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。Java工程对应jar包，Web工程对应war包。
6) 安装：在Maven环境下特指将打包的结果——jar包或war包安装到本地仓库（maven）中。
7) 部署：将打包的结果部署到远程仓库或将war包部署到服务器上运行。
Maven可以自动的从构建过程的起点一直执行到终点

二、Maven作用

 Maven是干什么用的？这是很多同学在学完这个课程后最大的问题。之所以会提出这个问题，是因为即使不使用Maven我们仍然可以进行B/S结构项目的开发。从表述层、业务逻辑层到持久化层再到数据库都有成熟的解决方案——不使用Maven我们一样可以开发项目啊？所以我们有必要通过企业开发中的实际需求来看一看哪些方面是我们现有技术的不足。

（一）添加第三方jar包

在今天的JavaEE开发领域，有大量的第三方框架和工具可以供我们使用。要使用这些jar包最简单的方法就是复制粘贴到WEB-INF目录下的lib目录下。但是这会导致每次创建一个新的工程就需要将jar包重复复制到lib目录下，从而造成工作区中存在大量重复的文件。
 而使用Maven后每个jar包只在本地仓库中保存一份，需要jar包的工程只需要维护一个文本形式的jar包的引用——我们称之为“坐标”。不仅极大的节约了存储空间，让项目更轻巧，更避免了重复文件太多而造成的混乱。

（二） jar包之间的依赖关系

jar包往往不是孤立存在的，很多jar包都需要在其他jar包的支持下才能够正常工作，我们称之为jar包之间的依赖关系。最典型的例子是：commons-fileupload-1.3.jar依赖于commons-io-2.0.1.jar，如果没有IO包，FileUpload包就不能正常工作。
 那么问题来了，你知道你所使用的所有jar包的依赖关系吗？当你拿到一个新的从未使用过的jar包，你如何得知他需要哪些jar包的支持呢？如果不了解这个情况，导入的jar包不够，那么现有的程序将不能正常工作。再进一步，当你的项目中需要用到上百个jar包时，你还会人为的，手工的逐一确认它们依赖的其他jar包吗？这简直是不可想象的。

（三） 获取第三方jar包

JavaEE开发中需要使用到的jar包种类繁多，几乎每个jar包在其本身的官网上的获取方式都不尽相同。为了查找一个jar包找遍互联网，身心俱疲，没有经历过的人或许体会不到这种折磨。不仅如此，费劲心血找的jar包里有的时候并没有你需要的那个类，又或者又同名的类没有你要的方法——以不规范的方式获取的jar包也往往是不规范的。
使用Maven我们可以享受到一个完全统一规范的jar包管理体系。你只需要在你的项目中以坐标的方式依赖一个jar包，Maven就会自动从中央仓库进行下载，并同时下载这个jar包所依赖的其他jar包——规范、完整、准确！一次性解决所有问题！

（四） 将项目拆分成多个工程模块

 随着JavaEE项目的规模越来越庞大，开发团队的规模也与日俱增。一个项目上千人的团队持续开发很多年对于JavaEE项目来说再正常不过。那么我们想象一下：几百上千的人开发的项目是同一个Web工程。那么架构师、项目经理该如何划分项目的模块、如何分工呢？这么大的项目已经不可能通过package结构来划分模块，必须将项目拆分成多个工程协同开发。多个模块工程中有的是Java工程，有的是Web工程。

（五）实现项目的分布式部署

 在实际生产环境中，项目规模增加到一定程度后，可能每个模块都需要运行在独立的服务器上，我们称之为分布式部署，这里同样需要用到Maven。

三、Maven 如何使用

（一）下载安装

1) 下载路径：http://maven.apache.org/download.cgi 
2) 解压：要求目录不要过深、不要有中文和特殊符号 
3) 必须配置JAVA_HOME 环境变量 
4) 配置环境变量  
MAVEN_HOME 值为Maven的解压路径 
在path中配置 %MAVEN_HOME%\bin 
5) 查看安装是否正确：在doc中 通过命令：mvn -v

配置本地仓库

1)  Maven的核心程序并不包含具体功能，仅负责宏观调度。具体功能由插件来完成。Maven核心程序会到本地仓库中查找插件。如果本地仓库中没有就会从远程中央仓库下载。此时如果不能上网则无法执行Maven的具体功能。为了解决这个问题，我们可以将Maven的本地仓库指向一个在联网情况下下载好的目录。 
2) Maven默认的本地仓库 C:\Users\ljw\.m2\repository目录。 
3) Maven的核心配置文件位置 D:\javaTools3\apache-maven-3.5.2\conf\settings.xml 
4) 在配置文件中设置本地仓库 <localRepository>D:\javaTools3\RepMaven</localRepository>

（二）第一个Maven程序

 Maven可以帮助我们从项目从0到1，管理

1) 创建约定的目录结构

demo1  src  ——main   ————java   ————resources（比如c3p0.xml）   ——test   ————java   ————resources  pom.xml main目录用于存放主程序。 test目录用于存放测试程序。 java目录用于存放源代码文件。 resources目录用于存放配置文件和资源文件。

2) 创建Maven的核心配置文件pom.xml

<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0"    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.offcn</groupId> <artifactId>demo1</artifactId> <version>1.0-SNAPSHOT</version> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.11</version> <scope>test</scope> </dependency> </dependencies> </project>

3) 编写主代码

在src\main\java\com\offcn\demo 目录下新建文件HelloWorld.java package com.offcn.demo; 
public class HelloWorld{ 
public String show(){ 
return "Helloworld!"; 
    } 
}

4) 编写测试代码

在src\test\java\com\offcn\test 目录下新建文件TestHelloWorld.java package com.offcn.test; import org.junit.Test; import com.offcn.demo.HelloWorld; 
public class TestHelloWorld{ 
@Test 
public void test(){          
HelloWorld helloWorld = new HelloWorld();          
String str = helloWorld.show();          
System.out.println(str); 
    } 
}

5) 运行几个基本的Maven命令

打开cmd命令行，进入Hello项目根目录(pom.xml文件所在目录)执行mvn compile命令，查看根目录变化 
cmd 中继续录入mvn clean命令，然后再次查看根目录变化 
cmd 中录入 mvn  compile命令, 查看根目录变化 
cmd 中录入 mvn  test-compile命令， 查看target目录的变化 
cmd 中录入 mvn  test命令，查看target目录变化 
cmd 中录入 mvn  package命令,查看target目录变化 
cmd 中录入 mvn  install命令， 查看本地仓库的目录变化 注意：运行Maven命令时一定要进入pom.xml文件所在的目录！

四、Maven的核心概念

相关概念

1) POM 2) 约定的目录结构 3）坐标 4）依赖 5）仓库 6）生命周期 7）插件和目标 8）继承 9）聚合

（一）POM

 Project Object Model：项目对象模型。将Java工程的相关信息封装为对象作为便于操作和管理的模型。Maven工程的核心配置。可以说学习Maven就是学习pom.xml文件中的配置。

（二）目录结构

 现在JavaEE开发领域普遍认同一个观点：约定>配置>编码。意思就是能用配置解决的问题就不编码，能基于约定的就不进行配置。而Maven正是因为指定了特定文件保存的目录才能够对我们的Java工程进行自动化构建

（三）坐标

1) Maven的坐标（类似几何的坐标）

使用如下三个向量在Maven的仓库中唯一的确定一个Maven工程。 一般使用gav 表示maven的坐标 
[1]groupId：公司或组织的域名倒序+当前项目名称 
[2]artifactId：当前项目的模块名称 
[3]version：当前模块的版本 
[4]如: <groupId>com.ujiuye</groupId> 
<artifactId>Demo1</artifactId> 
<version>1.0-SNAPSHOT</version>

2) 如何通过坐标到仓库中查找jar包

[1]将gav三个向量连起来 com.ujiuye.maven+Demo1+1.0-SNAPSHOT 
[2]以连起来的字符串作为目录结构到仓库中查找 com/ujiuye/maven/Demo1/0.0.1-SNAPSHOT/Demo1-0.0.1-SNAPSHOT.jar      junit/junit/4.11

3) 注意

我们自己的Maven工程必须执行安装操作才会进入仓库。安装的命令是：mvn install

（四）Maven的常用命令

mvn clean 清理输出目录target 
mvn compile  编译代码 
mvn test     运行测试代码 
mvn package  打包（具体根据pom文件配置的打包方式决定） 
mvn install  在本地仓库安装jar包

五、仓库

1) 分类

① 本地仓库：为当前本机电脑上的所有Maven工程服务。 ② 远程仓库 [1] 私服：架设在当前局域网环境下，为当前局域网范围内的所有Maven工程服务。

 [2]中央仓库：架设在Internet上，为全世界所有Maven工程服务。 [3]中央仓库的镜像：架设在各个大洲，为中央仓库分担流量。减轻中央仓库的压力，同时更快的响应用户请求。     阿里云的镜像  华为的镜像

2) 仓库中的文件

① Maven的插件 ② 我们自己开发的项目的模块 ③ 第三方框架或工具的jar包 ※不管是什么样的jar包，在仓库中都是按照坐标生成目录结构，所以可以通过统一的方式查询或依赖。

六、Maven 整合 Idea

1) 在idea中配置Maven

七、idea创建maven项目

（一）创建Maven的Java项目

（二）创建Maven的JavaWeb项目

在创建Java项目的基础上

八、依赖管理

1) 基本概念

 当A jar包需要用到B jar包中的类时，我们就说A对B有依赖。例如：commons-fileupload-1.3.jar依赖于commons-io-2.0.1.jar。 通过第二个Maven工程我们已经看到，当前工程会到本地仓库中根据坐标查找它所依赖的jar包。 配置的基本形式是使用dependency标签指定目标jar包的坐标。 <dependencies> <dependency> <!—坐标 --> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> <!-- 依赖的范围 --> <scope>test</scope> </dependency> </dependencies>

2)  直接依赖和间接依赖

如果A依赖B，B依赖C，那么A→B和B→C都是直接依赖，而A→C是间接依赖。

3)  依赖的范围

① compile [1]main目录下的Java代码可以访问这个范围的依赖 [2]test目录下的Java代码可以访问这个范围的依赖 [3]部署到Tomcat服务器上运行时要放在WEB-INF的lib目录下 例如：对Demo1的依赖。主程序、测试程序和服务器运行时都需要用到。 ② test [1]main目录下的Java代码不能访问这个范围的依赖 [2]test目录下的Java代码可以访问这个范围的依赖 [3]部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下 例如：对junit的依赖。仅仅是测试程序部分需要。 ③ provided [1]main目录下的Java代码可以访问这个范围的依赖 [2]test目录下的Java代码可以访问这个范围的依赖 [3]部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下 例如：servlet-api在服务器上运行时，Servlet容器会提供相关API，所以部署的时候不需要。 ④ 其他：runtime、import、system等。

（一）依赖的传递性

 当存在间接依赖的情况时，主工程对间接依赖的jar可以访问吗？这要看间接依赖的jar包引入时的依赖范围——只有依赖范围为compile时可以访问。

（二）依赖的排除

假设:  当前工程为public，直接依赖environment。environment依赖commons-logging的1.1.1对于public来说是间接依赖。当前工程public直接依赖commons-logging的1.1.2.加入exclusions配置后可以在依赖environment的时候排除版本为1.1.1的commons-logging的间接依赖。 
<dependency> 
    <groupId>com.ujiuye.maven</groupId> 
    <artifactId>Environment</artifactId> 
    <version>0.0.1-SNAPSHOT</version> 
<!-- 依赖排除 -->
     <exclusions> 
     <exclusion> 
     <groupId>commons-logging</groupId> 
     <artifactId>commons-logging</artifactId> 
     </exclusion>
      </exclusions> 
  </dependency> 
  <dependency>
       <groupId>commons-logging</groupId> 
       <artifactId>commons-logging</artifactId>
        <version>1.1.2</version> 
    </dependency>

（三）统一管理目标jar包的版本

 以对Spring的jar包依赖为例：Spring的每一个版本中都包含spring-core、spring-context等jar包。我们应该导入版本一致的Spring jar包，而不是使用4.0.0的spring-core的同时使用4.1.1的spring-context。

<dependency> 
<groupId>org.springframework</groupId> 
<artifactId>spring-core</artifactId> 
<version>4.0.0.RELEASE</version> 
</dependency> 
<dependency> 
<groupId>org.springframework</groupId>
 <artifactId>spring-context</artifactId>
  <version>4.0.0.RELEASE</version>
   </dependency> 
   <dependency> 
   <groupId>org.springframework</groupId> 
   <artifactId>spring-jdbc</artifactId>
    <version>4.0.0.RELEASE</version>
     </dependency> 
     <dependency> 
     <groupId>org.springframework</groupId> 
     <artifactId>spring-orm</artifactId> 
     <version>4.0.0.RELEASE</version> 
     </dependency> 
     <dependency> 
     <groupId>org.springframework</groupId>
      <artifactId>spring-web</artifactId> 
      <version>4.0.0.RELEASE</version>
       </dependency> 
       <dependency>
        <groupId>org.springframework</groupId>
         <artifactId>spring-webmvc</artifactId> 
         <version>4.0.0.RELEASE</version> 
         </dependency>