参考博客：https://blog.csdn.net/xiaodi2016/article/details/121341063













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

任何一个Maven工程会根据坐标到本地仓库中去查找它所依赖的jar包。如果能够找到则可以正常工作，否则就不行。HelloFriend 回到本地仓库去找HelloWorld jar包。
4.5 依赖管理
当A jar包需要用到B jar包中的类时，我们就说A对B有依赖。

直接依赖和间接依赖
如果A依赖B，B依赖C，那么A→B和B→C都是直接依赖，而A→C是间接依赖。
4.5.1 依赖的范围
依赖的范围：类似于变量的作用域，jar包可以使用的范围
<scope></scope>指明依赖范围
compile：
默认值，可以使用在main目录与test目录下使用
部署到Tomcat服务器上运行时要放在WEB-INF的lib目录下
test：
只能在test目录下使用
部署时无需上传服务器，服务器上没有是没有问题的
provided：
可以使用在main目录与test目录下使用
部署时无需上传服务器，因为服务器上理论上是已经存在的了(假定)

4.5.2 依赖的传递性
当存在间接依赖的情况时，主工程对间接依赖的jar可以访问吗？这要看间接依赖的jar包引入时的依赖范围——只有依赖范围为compile时可以访问。
间接依赖是否可以用还需要看依赖的范围，只有是complie才可以间接依赖。
原则：最短路径者优先和先声明者优先

如果可以不去依赖某个工程的jar包可以使用<exclusion>标签
<exclusions>
<exclusion>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</exclusion>
</exclusions>

4.5.3 统一管理目标Jar包的版本
以对Spring的jar包依赖为例：Spring的每一个版本中都包含spring-context，springmvc等jar包。我们应该导入版本一致的Spring jar包，而不是使用4.0.0的spring-context的同时使用4.1.1的springmvc。
问题是如果我们想要将这些jar包的版本统一升级为4.1.1，显然，我们有统一配置的方式：


4.6:仓库：
（1）本地仓库：为当前本机电脑上的所有Maven工程服务。

（2）远程仓库

    a）私服：架设在当前局域网环境下，为当前局域网范围内的所有Maven工程服务。

    b）中央仓库：架设在Internet上，为全世界所有Maven工程服务。

    c）中央仓库的镜像：架设在各个大洲，为中央仓库分担流量。减轻中央仓库的压力，同时更快的响应用户请求。

4.6.3：仓库中的文件
（1）Maven的插件

（2）我们自己开发的项目的模块

（3）第三方框架或工具的jar包

不管是什么样的jar包，在仓库中都是按照坐标生成目录结构，所以可以通过统一的方式查询或依赖。
4.7:maven生命周期
Maven生命周期定义了各个构建环节的执行顺序，有了这个清单，Maven就可以自动化的执行构建命令了。

• Clean Lifecycle在进行真正的构建之前进行一些清理工作。

• Default Lifecycle构建的核心部分，编译，测试，打包，安装，部署等等。(用的比较多，可以帮助我们自动化构建我们需要的内容)

• Site Lifecycle生成项目报告，站点，发布站点。(在浏览器上查看项目的信息，是site阶段和site-deploy阶段，用以生成和发布Maven站点，这可是Maven相当强大的功能，文档及统计数据自动生成，但是一般我们用不上)
  4.7.1：生命周期与自动化构建
  运行任何一个阶段的时候，它前面的所有阶段都会被运行，例如我们运行mvn install 的时候，代码会被编译，测试，打包。这就是Maven为什么能够自动执行构建过程的各个环节的原因。此外，Maven的插件机制是完全依赖Maven的生命周期的。
  4.8：插件和目标
  （1）Maven的核心仅仅定义了抽象的生命周期，具体的任务都是交由插件完成的。
  （2）每个插件都能实现多个功能，每个功能就是一个插件目标。
  （3）Maven的生命周期与插件目标相互绑定，以完成某个具体的构建任务。
  例如：compile就是插件maven-compiler-plugin的一个功能；pre-clean是插件maven-clean-plugin的一个目标。
  五：继承与聚合
  5.1：为什么需要继承机制？
  由于非compile范围的依赖信息是不能在“依赖链”中传递的，所以有需要的工程只能单独配置。
  父项目一般不做业务处理，所以无需打包，并且无需保留src目录
  需要在父项目中声明标签 可以传的值有：

    pom：不打包
    jar：默认值，打包时打成jar包
    war：打包时打成war包
  

子项目应该声明代码知道父项目是谁

5.2：父项目的导包方式：
方式一：
结果：子项目中直接拥有父项目中的所有jar包

方式二：
结果：父项目中实际上没有导包进入，只不过进行了声明，子项目需要再次导入声明，但是此时无需指定版本

原因：父项目作为整个项目的管理者，没有业务逻辑代码，所以本身不需要导包，父项目只不过作为jar包管理，这里可能有很多的jar包，子项目中可以根据需求进行声明。
5.3：聚合：
5.3.1:为什么要使用聚合？
将多个工程拆分为模块后，需要手动逐个安装到仓库后依赖才能够生效。修改源码后也需要逐个手动进行clean操作。而使用了聚合之后就可以批量进行Maven工程的安装、清理工作,方便管理。
5.3.2:配置：
(在父项目中进行配置，目的是父亲知道谁是它的儿子，这样的话才能统一管理子项目)