文章目录
使用Maven的优势
maven是干什么用，的我们先通过企业开发中的时间需求来看一看那些方面是我们技术不足。
第三方jar包添加
java项目，每个项目需要复制一份jar包，Maven后只在本地仓库中保存一份
第三方jar包获取
java项目，自己去网上找jar包，费劲心血找的jar包里面有的时候并没有你需要的哪个类。
Maven就会自动从仓库进行下载，并同时下载这个jar包所依赖的其他jar包，规范，完整，准确
JavaEE开发中需要使用到的jar包种类繁多，几乎每个jar包在其本身的官网上的获取方式都不尽相同。为了查找一个jar包找遍互联网，身心俱疲，没有经历过的人或许体会不到这种折磨。不仅如此，费劲心血找的jar包里有的时候并没有你需要的那个类，又或者有同名的类没有你要的方法------以不规范的方式获取的jar包也往往是不规范的。
使用Maven我们可以享受到一个完全统一规范的jar包管理体系。你只需要在你的项目中以坐标的方式依赖一个jar包，Maven就会自动从中央仓库进行下载，并同时下载这个jar包所依赖的其他jar包------规范、完整、准确！一次性解决所有问题！
jar包之间的依赖关系
java项目，自己去网上找jar包，同时找到所有依赖关系的jatr包
Maven会自动从仓库进行下载，下载这个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包吗？这简直是不可想象的。
而引入Maven后，Maven就可以替我们自动的将当前jar包所依赖的其他所有jar包全部导入进来，无需人工参与，节约了我们大量的时间和精力。用实际例子来说明就是：通过Maven导入commons-fileupload-1.3.jar后，commons-io-2.0.1.jar会被自动导入，程序员不必了解这个依赖关系。
jar包之间的冲突处理
上一点说的是jar包不足，项目无法正常工作，但其实有的时候jar包多了项目仍然无法正常工作，这就是jar包之间的冲突
举个例子：我们现在有三个工程MakeFriend、HelloFriend和Hello。MakeFriend依赖HelloFriend，HelloFriend依赖Hello。而Hello依赖log4j.1.2.17.jar，HelloFriend依赖log4j.1.2.14.jar。如下图所示：
那么MakeFriend工程的运行时环境中该导入log4j.1.2.14.jar呢还是log4j.1.2.17.jar呢？
这样的问题一个两个还可以手工解决，但如果系统中存在几十上百的jar包，他们之间的依赖关系会非常复杂，几乎不可能手工实现依赖关系的梳理。
使用Maven就可以自动的处理jar包之间的冲突问题。因为Maven中内置了两条依赖原则：最短路径者优先和先声明者优先，上述问题MakeFriend工程会自动使用log4j.1.2.14.jar。
将项目拆分成多个工程模块
随着JavaEE项目的规模越来越庞大，开发团队的规模也与日俱增。一个项目上千人的团队持续开发很多年对于JavaEE项目来说再正常不过。那么我们想象一下：几百上千的人开发的项目是同一个Web工程。那么架构师、项目经理该如何划分项目的模块、如何分工呢？这么大的项目已经不可能通过package结构来划分模块，必须将项目拆分成多个工程协同开发。多个模块工程中有的是Java工程，有的是Web工程。
那么工程拆分后又如何进行互相调用和访问呢？这就需要用到Maven的依赖管理机制。例如：某项目拆分的情况如下。
上层模块依赖下层，所以下层模块中定义的API都可以为所调用和访问
实现项目的分布式部署
在实际开发环境中，项目规模增加到一定的程度后，可能每个模块都需要运行在独立的服务器上，我们称之为分布式部署，这里同样需要用到Maven
Maven是什么
如果上面的描述能够是你认识到使用Maven是多么的重要，我们下面就来介绍一下Maven是什么
自动化构建工具
（1）Maven这个单词的本意是：专家，内行。读音是['meɪv(ə)n]或['mevn]，不要读作"妈文"。
（2）Maven是一款自动化构建工具，专注服务于Java平台的项目构建和依赖管理。在JavaEE开发的历史上构建工具的发展也经历了一系列的演化和变迁：Make→Ant→Maven→Gradle→其他......
构建的概念
构建并不是创建，创建一个工程并不等于构建一个项目，要了解构建的含义我们应该由浅入深的从以下三个层面来看
（1）纯java代码
大家都知道，我们Java是一门编译型语言，.java扩展名的源文件需要编译成.class扩展名的字节码文件才能够执行。所以编写任何Java代码想要执行的话就必须经过编译得到对应的.class文件。
（2）Web工程
当我们需要通过浏览器访问Java程序时就必须将包含Java程序的Web工程编译的结果"拿"到服务器上的指定目录下，并启动服务器才行。这个"拿"的过程我们叫部署。
我们可以将未编译的Web工程比喻为一只生的鸡，编译好的Web工程是一只煮熟的鸡，编译部署的过程就是将鸡炖熟。
Web工程和其编译结果的目录结构对比见下图：
（3）实际项目
在实际项目中整合第三方框架，Web工程中除了Java程序和JSP页面、图片等静态资源之外，还包括第三方框架的jar包以及各种各样的配置文件。所有这些资源都必须按照正确的目录结构部署到服务器上，项目才可以运行。
所以综上所述：构建就是以我们编写的Java代码、框架配置文件、国际化等其他资源文件、JSP页面和图片等静态资源作为"原材料"，去"生产"出一个可以运行的项目的过程。
那么项目构建的全过程中都包含哪些环节呢？
构建环节
（1）清理：删除以前的编译结果，为重新编译做好准备。
（2）编译：将Java源程序编译为字节码文件。
（3）测试：针对项目中的关键点进行测试，确保项目在迭代开发过程中关键点的正确性。
（4）报告：在每一次测试后以标准的格式记录和展示测试结果。
（5）打包：将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。Java工程对应jar包，Web工程对应war包。
（6）安装：在Maven环境下特指将打包的结果------jar包或war包安装到本地仓库中。
（7）部署：将打包的结果部署到远程仓库或将war包部署到服务器上运行。
自动化构建
其实上述环节我们在IDEA中都可以找到对应的操作，只是不太标准。那么既然IDE已经可以进行构建了我们为什么还要使用Maven这样的构建工具呢？我们来看一个小故事：
这是阳光明媚的一天。托马斯向往常一样早早的来到了公司，冲好一杯咖啡，进入了自己的邮箱------很不幸，QA小组发来了一封邮件，
报告了他昨天提交的模块的测试结果------有BUG。"好吧，反正也不是第一次"，托马斯摇摇头，进入IDE，运行自己的程序，编译、打包、
部署到服务器上，然后按照邮件中的操作路径进行测试。"嗯，没错，这个地方确实有问题"，托马斯说道。于是托马斯开始尝试修复这个BUG
，当他差不多有眉目的时候已经到了午饭时间。
下午继续工作。BUG很快被修正了，接着托马斯对模块重新进行了编译、打包、部署，测试之后确认没有问题了，回复了QA小组的邮件。
一天就这样过去了，明媚的阳光化作了美丽的晚霞，托马斯却觉得生活并不像晚霞那样美好啊。
梳理以下托马斯一天中的工作内容
从中我们发现，托马斯的很大一部分时间花在了"编译、打包、部署、测试"这些程式化的工作上面，而真正需要由人的智慧实现的分析问题和编译却只占了很少一部分
能否将这些程式化的工作交给机器自动完成那？当然可以 这就是自动化构建
那么Maven又是如何实现自动化的构建的那？简单的说来就是他可以自动地从构建过程的起点一直执行到终点
Maven如何使用
在这一节中，我们来看看Maven核心程序的安装和本地仓库的必要设置。然后我们就可以编写第一个Maven程序了
安装Maven核心程序
1）检查JAVA_HOME环境变量。Maven是使用Java开发的，所以必须知道当前系统环境中JDK的安装目录。
2）解压Maven的核心程序。将apache-maven-3.5.4-bin.zip解压到一个非中文无空格的目录下。例如
D:\develop\Maven\apache-maven-3.5.4
3）配置环境变量。
（1）在系统变量里面创建MAVEN_HOME变量，并赋值
变量：MAVEN_HOME
值：D:\develop\Maven\apache-maven-3.5.4
（2）在Path变量中，添加maven环境变量
变量：Path
值：%MAVEN_HOME%\bin或D:\develop\Maven\apache-maven-3.5.4\bin
4）查看Maven版本信息验证安装是否正确
（1）按Win +r，进入电脑运行模式；
（2）在打开里面输入：cmd
（3）在管理员窗口输入
mvn -v
maven联网问题
Maven中的settings配置
（1）Maven默认的本地仓库：~.m2\repository目录。
说明：~表示当前用户的家目录。
（2）Maven的核心配置文件位置：
解压目录D:\develop\Maven\apache-maven-3.5.4\conf\settings.xml
打开设置文件，我们需要手动配置几个设置
首先修改默认仓库的位置
java
<localRepository>D:\develop\repository</localRepository>配置镜像
java
<mirrors>
<!-- mirror
| Specifies a repository mirror site to use instead of a given repository. The repository that
| this mirror serves has an ID that matches the mirrorOf element of this mirror. IDs are used
| for inheritance and direct lookup purposes, and must be unique across the set of mirrors.
|
-->
<mirror>
<id>aliyunmaven</id>
<mirrorOf>*</mirrorOf>
<name>阿里云公共仓库</name>
<url>https://maven.aliyun.com/repository/public</url>
</mirror>
</mirrors>设置maven编译版本
java
<profiles>
<profile>
<id>jdk-1.8</id>
<activation>
<activeByDefault>true</activeByDefault>
<jdk>1.8</jdk>
</activation>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>
</properties>
</profile>
</profiles>在idea中配置Maven
首先我们先创建一个新项目
创建空白项目
项目创建完毕后，就可以配置Maven的设置
对三个位置进行修改
在maven的importing设置下修改
设置完成后就可新建一个maven模块
选择maven
配置设置
配置maven的核心配置文件pom.xml
添加代码块
java
<?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.atguigu.maven</groupId>
<artifactId>Hello</artifactId>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
</dependencies>使用maven的方式运行maven工程
来到bigdata的根目录
（1）compile命令，编译主程序
（2）clean 清理编译的程序
（3）test 编译测试程序，并且运行
（4）package打包，工程需要发到服务器上运行时
发现打了jar包
（5）将jar包安装到本地仓库，注意是根据我们建立maven时项目名，模块名版本的路径去寻找
Maven打包插件
maven本身的打包插件不负责将依赖的jar包一并打入到jar包，如果项目所依赖的jar包在服务器环境中提供了则可以使用，如果服务其中，没用提供相关的类则会无法查找
因此需要一款能够将项目依赖的jar包一并打入到jar中的插件来解决这些问题
可以在pom中添加如下内容
javascript
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>Maven核心概念
Maven的核心概念包括：POM约定的目录结构、坐标、依赖、仓库、生命周期、插件和目录、继承、聚合
POM
Project Object Model：项目对象模型。将Java工程的相关信息封装为对象作为便于操作和管理的模型。Maven工程的核心配置。可以说学习Maven就是学习pom.xml文件中的配置。
约定的目录结构
现在JavaEE开发领域普遍认同一个观点：约定>配置>编码。意思就是能用配置解决的问题就不编码，能基于约定的就不进行配置。而Maven正是因为指定了特定文件保存的目录才能够对我们的Java工程进行自动化构建。
标准的maven结构
坐标
1）几何中的坐标
（1）在一个平面中使用x、y两个向量可以唯一的确定平面中的一个点。
（2）在空间中使用x、y、z三个向量可以唯一的确定空间中的一个点。
2）Maven的坐标
使用如下三个向量在Maven的仓库中唯一的确定一个Maven工程。
（1）groupId：公司或组织的域名倒序+当前项目名称
（2）artifactId：当前项目的模块名称
（3）version：当前模块的版本
在项目的pom.xml文件中存储坐标
如何通过坐标到仓库中查找jar包
将三个坐标给连起来，在本地仓库中查找，这就是我们jar包的位置
注意：我们自己的Maven工程必须执行安装操作才会进入仓库。安装的命令是：mvn install
第二个Maven工程
方法和上面等同，三个坐标为
在pom.xml中配置文件中当前工程依赖的hello和junit
在main的java下创建主程序
创建测试程序
关键，对hello的依赖
这里的hello就是我们的第一个maven工程，现在hellofrind对他有依赖，那么这个依赖能否能成功，更进一步的问题是：HelloFriend工程会到哪里去找Hello呢？
答案是：本地仓库。任何一个Maven工程会根据坐标到本地仓库中去查找它所依赖的jar包。如果能够找到则可以正常工作，否则就不行
依赖管理
1.基本概念
当A jar包需要用到B jar包中的类时，我们就说A对B有依赖。例如：HelloFriend-1.0-SNAPSHOT.jar依赖于Hello-1.0-SNAPSHOT.jar。
通过第二个Maven工程我们已经看到，当前工程会到本地仓库中根据坐标查找它所依赖的jar包。
配置的基本形式是使用dependency标签指定目标jar包的坐标。例如：
2）直接依赖和间接依赖
如果A依赖B，B依赖C，那么A→B和B→C都是直接依赖，而A→C是间接依赖
依赖的范围
1）compile（默认就是这个范围）
（1）main目录下的Java代码可以访问这个范围的依赖
（2）test目录下的Java代码可以访问这个范围的依赖
（3）部署到Tomcat服务器上运行时要放在WEB-INF的lib目录下
例如：对Hello的依赖。主程序、测试程序和服务器运行时都需要用到。
2）test
（1）main目录下的Java代码不能访问这个范围的依赖
（2）test目录下的Java代码可以访问这个范围的依赖
（3）部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下
例如：对junit的依赖。仅仅是测试程序部分需要。
3）provided
（1）main目录下的Java代码可以访问这个范围的依赖
（2）test目录下的Java代码可以访问这个范围的依赖
（3）部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下
例如：servlet-api在服务器上运行时，Servlet容器会提供相关API，所以部署的时候不需要。
4）其他：runtime、import、system等。
各个依赖范围的作用可以概括为下图：
依赖的传递性
当存在间接依赖的情况时，主工程对间接依赖的jar可以访问吗？这要看间接依赖的jar包引入时的依赖范围------只有依赖范围为compile时可以访问。例如：
依赖的原则，解决jar包冲突
1）路径最短者优先
2）路径相同时先声明者优先
这里"声明"的先后顺序指的是dependency标签配置的先后顺序。
依赖的排除
有的时候为了确保程序正确可以将有可能重复的间接依赖排除。请看如下的例子：
（1）假设当前工程为MakeFriend，直接依赖OurFriends。
（2）OurFriends依赖commons-logging的1.1.1对于MakeFriend来说是间接依赖。
（3）当前工程MakeFriend直接依赖commons-logging的1.1.2。
（4）加入exclusions配置后可以在依赖OurFriends的时候排除版本为1.1.1的commons-logging的间接依赖。
javascript
<dependency>
<groupId>com.atguigu.maven</groupId>
<artifactId>OurFriends</artifactId>
<version>1.0-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>