为啥要用maven
1、不用认为添加jar包所依赖的其他jar包
2、能在本地仓库只保留一份jar包，避免了多个工程使用相同jar包，需要重复导入的问题，减少冗余
3、能够规范添加jar包，在下载需要的jar包时有多种方法，但是不能保证我们下载的规范、准确，使用maven后可以通过坐标告诉maven我们需要的jar包，而maven会自动去中央仓库下载这个jar包及其及其依赖的所有jar包
4、便于将项目进行拆分，形成多个工程模块。一个大型的Java项目，其中可能需要拆分成多个模块同时进行开发，有的可能是Java工程，有的可能是web工程等等，拆分后的工程之间如何相互调用等问题，可以通过maven实现
maven
是一款自动化构建工具
作用：构建项目和管理依赖
什么是构建
主要从三个层面看：
java代码：执行之前必须通过编译器编译成class文件
web工程：想通过浏览器访问Java程序，需要将其（Java程序）对应的web工程的编译结果放到服务器的相关路径下，这个过程叫部署，并启动服务器。
项目：需要一些第三方框架和jar包等资源
构建就是将编写的java代码，配置文件，图片等资源，作为原材料，形成一个能够运行的项目的过程
构建的主要环节
①清理：删除以前的编译结果，为重新编译做好准备。
②编译：将 Java 源程序编译为字节码文件。
③测试：针对项目中的关键点进行测试，确保项目在迭代开发过程中关键点的正确性。
④报告：在每一次测试后以标准的格式记录和展示测试结果。
⑤打包：将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。Java 工程对应 jar 包，Web 工程对应 war 包。
⑥安装：在 Maven 环境下特指将打包的结果——jar 包或 war 包安装到本地仓库中。
⑦部署：将打包的结果部署到远程仓库或将 war 包部署到服务器上运行。
但是这些过程IDEA也可以实现，为啥用maven？
因为一个项目如果出了问题，在IDEA上，程序员需要人工执行构建的这几个过程，然后改代码，再通过这些过程之后，将项目交给负责人，其中大部分时间都花费在这些无用的步骤上。
改进：自动化构建，将这几个步骤让机器完成（maven实现）
maven核心概念
约定的项目结构
比如说，在java文件编译时，需要知道zhegejava文件的具体位置，编译后的字节码文件存放的位置也需要明确，有两种方式：
①通过配置的形式明确告诉它
②基于第三方工具或框架的约定（maven用的）
而 Maven 正是因为指定了特定文件保存的目录才能够对我们的 Java 工程进行 自动化构建。
POM
Project Object Model：项目对象模型。
将 Java 工程的相关信息封装为对象作为便于操作和管理的模型。
Maven 工程的核心配置。可以说学习 Maven 就是学习 pom.xml 文件中的配置。
坐标
几何中的坐标：
[1]在一个平面中使用 x、y 两个向量可以唯一的确定平面中的一个点。
[2]在空间中使用 x、y、z 三个向量可以唯一的确定空间中的一个点。
Maven 的坐标
使用如下三个向量在 Maven 的仓库中唯一的确定一个 Maven 工程。
[1]groupid：公司或组织的域名倒序+当前项目名称
[2]artifactId：当前项目的模块名称
[3]version：当前模块的版本
<groupId>com.atguigu.maven</groupId>
<artifactId>Hello</artifactId>
<version>0.0.1-SNAPSHOT</version>
如何找的？
将 三个向量连起来：com.atguigu.maven+Hello+0.0.1-SNAPSHOT
以连起来的字符串作为目录结构到仓库中查找：com/atguigu/maven/Hello/0.0.1-SNAPSHOT/Hello-0.0.1-SNAPSHOT.jar
依赖
使用 Maven 最主要的就是使用它的依赖管理功能
依赖的目的是什么
当 A jar 包用到了 B jar 包中的某些类时，A 就对 B 产生了依赖，这是概念上的描述。那么如何在项目 中以依赖的方式引入一个我们需要的 jar 包呢？ 答案非常简单，就是使用 dependency 标签指定被依赖 jar 包的坐标就可以了：
<dependency>
<groupId>com.atguigu.maven</groupId>
<artifactId>Hello</artifactId>
<version>0.0.1-SNAPSHOT</version>
<scope>compile</scope>
</dependency>
依赖的范围
上面除了目标 jar 包的坐标还有一个 scope 设置，这是依赖的范围。
依赖的范 围有几个可选值，我们用得到的是：compile、test、provided 三个。
有效性总结：
依赖的传递性
a包依赖b，b包依赖c，那a能不能使用c呢？看的是依赖的范围是否是compile：
依赖的排除
如果我们在当前工程中引入了一个依赖是 A，而 A 又依赖了 B，那么 Maven 会自动将 A 依赖的 B 引入当 前工程，但是个别情况下 B 有可能是一个不稳定版，或对当前工程有不良影响。这时我们可以在引入 A 的时 候将 B 排除。
<dependency>
<groupId>com.atguigu.maven</groupId>
<artifactId>HelloFriend</artifactId>
<version>0.0.1-SNAPSHOT</version>
<type>jar</type>
<scope>compile</scope>
<!-- 排除不必要的依赖-->
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
效果：
依赖的原则：解决 jar 包冲突
假设有如下依赖关系：
A->B->C->D1(log 15.0)：A中包含对B的依赖，B中包含对C的依赖，C中包含对D1的依赖，假设是D1是日志jar包，version为15.0
E->F->D2(log 16.0)：E中包含对F的依赖，F包含对D2的依赖，假设是D2是同一个日志jar包，version为16.0
当我们在调用D2中的method1()方法，而D1中是15.0版本（method1可能是D升级后增加的方法），可能没有这个方法，这样JVM在加载A中D1依赖的时候，找不到method1方法，就会报NoSuchMethodError的错误，此时就产生了jar包冲突
注：
如果在调用method2()方法的时候，D1、D2都含有这个方法（且升级的版本D2没有改动这个方法，这样即使D有多个版本，也不会产生版本冲突的问题。）
最短路径优先:
Maven 面对 D1 和 D2 时，会默认选择最短路径的那个 jar 包，即 D2。E->F->D2 比 A->B->C->D1 路径短 1。
最先声明优先:
如果路径一样的话，如： A->B->C1, E->F->C2 ，两个依赖路径长度都是 2，那么就选择最先声明。
仓库
分类
[1]本地仓库：为当前本机电脑上的所有 Maven 工程服务.(为本地maven服务)
[2]远程仓库:
(2)中央仓库：架设在 Internet 上，为全世界所有 Maven 工程服务。
(3)中央仓库的镜像：架设在各个大洲，为中央仓库分担流量。减轻中央仓库的压力，同时更快的响应用户请求.(1)私服：架设在当前局域网环境下，为当前局域网范围内的所有 Maven 工程服务
仓库中的文件
[1]Maven 的插件
[2]我们自己开发的项目的模块
[3]第三方框架或工具的 jar 包
不管是什么样的 jar 包，在仓库中都是按照坐标生成目录结构，所以可以通过统一的方式查询或依赖
生命周期
什么是 Maven 的生命周期？
Maven 生命周期定义了各个构建环节的执行顺序。
Maven 有三套相互独立的生命周期，分别是：
①Clean Lifecycle 在进行真正的构建之前进行一些清理工作。
②Default Lifecycle 构建的核心部分，编译，测试，打包，安装，部署等等。
③Site Lifecycle 生成项目报告，站点，发布站点
它们是相互独立的，你可以仅仅调用 clean 来清理工作目录，仅仅调用 site 来生成站点
Clean 生命周期
Clean 生命周期一共包含了三个阶段：
①pre-clean 执行一些需要在 clean 之前完成的工作
②clean 移除所有上一次构建生成的文件
③post-clean 执行一些需要在 clean 之后立刻完成的工作
Site 生命周期
①pre-site 执行一些需要在生成站点文档之前完成的工作
②site 生成项目的站点文档
③post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
④site-deploy 将生成的站点文档部署到特定的服务器上
Default生命周期
Default 生命周期是 Maven 生命周期中最重要的一个，绝大部分工作都发生在这个生命周期中。这里， 只解释一些比较重要和常用的阶段：
validate
generate-sources
process-sources
generate-resources process-resources 复制并处理资源文件，至目标目录，准备打包。
compile 编译项目的源代码。
process-classes
generate-test-sources
process-test-sources
generate-test-resources
process-test-resources 复制并处理资源文件，至目标测试目录。
test-compile 编译测试源代码。
process-test-classes test 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。
prepare-package package 接受编译好的代码，打包成可发布的格式，如 JAR。
pre-integration-test integration-test post-integration-test verify install 将包安装至本地仓库，以让其它项目依赖。
deploy 将最终的包复制到远程的仓库，以让其它开发人员与项目共享或部署到服务器上运行
生命周期与自动化构建
运行任何一个阶段的时候，它前面的所有阶段都会被运行，例如我们运行 mvn install 的时候，代码会 被编译，测试，打包。这就是 Maven 为什么能够自动执行构建过程的各个环节的原因。此外，Maven 的插 件机制是完全依赖 Maven 的生命周期的，因此理解生命周期至关重要
插件和目标
●Maven 的核心仅仅定义了抽象的生命周期，具体的任务都是交由插件完成的。
●每个插件都能实现多个功能，每个功能就是一个插件目标。
●Maven 的生命周期与插件目标相互绑定，以完成某个具体的构建任务。
继承
为什么需要继承机制？
由于非 compile 范围的依赖信息是不能在“依赖链”中传递的，所以有需要的工程只能单独配置
假设各个项目的范围是test，都用到了Junit，现在想将Junit的版本改为4.9，可以将各个模块中对应的依赖信息提取到父工程模块中统一管理。
创建父工程
创建父工程和创建一般的 Java 工程操作一致，唯一需要注意的是：打包方式处要设置为 pom。
在子工程中引用父工程 :
<parent> <!-- 父工程坐标 -->
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>...</version>
<relativePath>从当前目录到父项目的 pom.xml 文件的相对路径</relativePath>
</parent>
<parent>
<groupId>com.atguigu.maven</groupId>
<artifactId>Parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<!-- 指定从当前子工程的pom.xml文件出发，查找父工程的pom.xml的路径 --> <relativePath>../Parent/pom.xml</relativePath>
</parent>
此时如果子工程的 groupId 和 version 如果和父工程重复则可以删除
在父工程中管理依赖
将 Parent 项目中的 dependencies 标签，用 dependencyManagement 标签括起来
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.9</version>
<scope>test</scope>
</dependency>
</dependencies>
</dependencyManagement>
在子项目中重新指定需要的依赖，删除范围和版本号：
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
</dependencies>
聚合
为什么要使用聚合？
将多个工程拆分为模块后，需要手动逐个安装到仓库后依赖才能够生效。修改源码后也需要逐个手动进 行 clean 操作。而使用了聚合之后就可以批量进行 Maven 工程的安装、清理工作
如何配置聚合？
在总的聚合工程中使用 modules/module 标签组合，指定模块工程的相对路径即可
聚合时 Maven 会帮助我们自动管理其相互之间的依赖关系,帮助我们省了很多的时间和精力
<modules>
<module>../Hello</module>
<module>../HelloFriend</module>
<module>../MakeFriends</module>
</modules>