Maven总结

1. 整体架构模型

2. 目前的技术在开发中存在的问题

1. 一个项目就是一个工程，如果项目非常庞大，就不适合继续使用package来划分模块。最好是每一个模块对应一个工程，利于分工协作。
   借助于maven就可以将一个项目拆分成多个工程。

2. 项目中需要的jar包必须手动“复制”、”粘贴” 到WEB-INF/lib 项目下
   带来的问题：同样的jar包文件重复出现在不同的项目工程中，一方面浪费存储空间，另外也让工程比较臃肿。
   借助Maven，可以将jar包仅仅保存在“仓库”中，有需要使用的工程“引用”这个文件，并不需要重复复制。

3. jar包需要别人替我们准备好，或到官网下载
   所有知名框架或第三方工具jar包已经按照统一规范放在了Maven的中央仓库中。

4. 一个jar包依赖的其他jar包需要自己手动加到项目中
   Maven会自动将被依赖的jar包导入进来。

3. Maven简介

1. Maven 是 Apache 软件基金会组织维护的一款自动化构建工具，专注服务于 Java 平台的项目构建和依赖管理。

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

3. 构建过程中的几个主要环节
   ① 清理：删除以前的编译结果，为重新编译做好准备。
   ② 编译：将Java源程序编译为字节码文件。
   ③ 测试：针对项目中的关键点进行测试，确保项目在迭代开发过程中关键点的正确性。
   ④ 报告：将每一次测试后以标准的格式记录和展示测试结果。
   ⑤ 打包：将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。Java工程对应jar包，Web工程对象war包。
   ⑥ 安装：在Maven环境下特指将打包的结果——Jar包或War包安装到本地仓库中。
   ⑦ 部署：将打包的结果部署到远程仓库或将war包部署到服务器上运行。

4. Maven的意义
   Maven可以自动地从构建过程的起点一直执行到终点。
   

4. 安装Maven核心程序

1. 检查JAVA_HOME环境变量
   
2. 解压Maven核心程序的压缩包，放在一个非中文、无空格的路径下

D:\develop\Java\apache-maven-3.6.3

3. 配置Maven相关的环境变量
   ① 把MAVEN_HOME变量及其路径加入系统变量
   
   ② 把bin目录加到path中
   
4. 运行 mvn -v 命令查看Maven版本
   

5. Maven工程目录结构

约定的目录结构

pom.xml文件为maven工程的核心配置文件。

6. 常用Maven命令

1. 注意：执行与构建过程相关的Maven命令，必须进入pom.xml所在的目录。
2. 常用命令
   [1] mvn clean : 清理
   [2] mvn compile : 编译主程序
   [3] mvn test-compile : 编译测试程序
   [4] mvn test : 执行测试
   [5] mvn package : 打包
   [6] mvn install ： 安装
   [7] mvn site ：生成站点

7. 关于联网问题

1. Maven 的核心程序中仅仅定义了抽象的生命周期，但是具体的工作必须有特定的插件来完成。而插件本身不包含在Maven核心程序中。
2. 当我们执行的Maven命令需要用到某些插件时，Maven核心程序会首先到本地仓库中查找。
3. 本地仓库的默认位置：[系统登陆用户的家目录] .m2\repository
   Maven核心程序如果在本地仓库中找不到需要的插件，那么它会自动连接外网，到中央仓库下载。
4. 如果此时无法连接外网，则构建失败。
5. 修改默认本地仓库的位置可以让Maven核心程序到我们事先准备好的目录下查找插件
   ① 找到Maven解压目录\conf\settings.xml
   ② 在setting.xml 文件中找到 localRepository 标签
   ③ 将< localRepository>/path/to/local/repo< /localRepository>从注释中取出
   ④ 将标签体内容修改为自定义的Maven仓库目录

8. POM

1. POM：Project Object Model 项目对象模型
   DOM：Document Object Model 文档对象模型

2. pom.xml是Maven工程的核心配置文件，与构建过程相关的一切设置都在这个文件中进行配置。

9. Maven坐标

1. 使用下面三个向量在仓库中唯一定位一个Maven工程。

• groupId：公司或组织域名倒序+项目名

<groupId>com.atguigu.maven</groupId>

• artifactId：模块名

<artifactId>Hello</artifactId>

• version：版本

<version>1.0.0</version>

2. Maven 工程的坐标与仓库中路径的对应关系，以spring为例

Maven坐标：
<groupId>org.springframework< /groupId>
<artifactId>spring-core</artifactId>
<version>4.0.0.RELEASE</version>
对应仓库路径：
org/springframework/spring-core/4.0.0.RELEASE/spring-core-4.0.0.RELEASE.jar

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

10. 仓库

1. 仓库的分类
   ① 本地仓库：当前电脑上部署的仓库目录，为当前电脑上所有Maven工程服务
   ② 远程仓库
   (1）私服：搭建在局域网环境中，为局域网范围内的所有Maven工程服务
   
   （2）中央仓库：假设在Internet上，为全世界所有Maven工程服务
   （3）中央仓库镜像：为了分担中央仓库流量，提升用户访问速度
2. 仓库中保存的内容：Maven工程
   ① Maven命令所需要的插件
   ② 第三方框架或工具的jar包
   ③ 我们自己开发的Maven工程

11. 依赖

1. 当 A jar 包用到了 B jar 包中的某些类时，A 就对 B 产生了依赖，这是概念上的描述。Maven解析依赖信息时会到仓库中查找被依赖的jar包。
   对于我们自己开发的Maven工程，使用mvn install命令安装后就可以进入仓库。

<dependency> 
    <groupId>com.atguigu.maven</groupId>  
    <artifactId>Hello</artifactId>  
    <version>0.0.1-SNAPSHOT</version>  
    <scope>compile</scope> 
</dependency>

2. 依赖的范围

• 从项目结构角度理解compile和test的区别
  

compile范围依赖

• 对主程序是否有效：有效
• 对测试程序是否有效：有效
• 是否参与打包：参与
• 是否参与部署：参与
• 典型例子：spring-core

test范围依赖

• 对主程序是否有效：无效
• 对测试程序是否有效：有效
• 是否参与打包：不参与
• 是否参与部署：不参与
• 典型例子：Junit

• 从开发和运行这两个阶段理解compile 和 provided 的区别
  
• 有效性总结
  

3. 依赖的传递性
   
4. 依赖的排除
   如果我们当前工程中引入了一个依赖A，而A又依赖了B，那么Maven会自动将A依赖的B引入当前工程，但是个别情况下B有可能是一个不稳定版本，或对当前工程有不良影响。这时我们可以在引入A的时候将B排除。
   ① 情景举例
   
   ② 配置方式
   
   ③ 排除后的效果
   
   可以看到，commons-logging这个jar包已经被排除了。
5. 统一管理所依赖jar包的版本
   对同一个框架的一组jar包最好使用相同的版本。为了方便升级架构，可以将jar包的版本信息统一提取出来。
   ① 统一声明版本号
   
   ② 引用前面声明的版本号
   
6. 依赖的原则，解决jar包冲突
   ① 路径最短者优先
   
   ② 路径相同时先声明者优先
   
   这里“声明”的先后顺序指的是 dependency 标签配置的先后顺序。

12. 生命周期

1. 各个构建环节执行的顺序：不能打乱顺序，必须按照既定的正确顺序来执行。
2. Maven的核心程序中定义了抽象的生命周期，生命周期中各个阶段的具体任务是由插件来完成的。
3. Maven核心程序为了更好的实现自动化构建，按照这一特点执行生命周期中各个阶段：不论现在要执行生命周期中的哪一阶段，都是从这个生命周期最初的位置开始执行。
4. Maven有三套相互独立的生命周期，分别是：
   ① Clean Lifecycle 在进行真正的构建之前进行一些清理工作。
   ② Default Lifecycle 构建的核心部分，编译、测试、打包、安装、部署等等。
   ③ Site Lifecycle 生成项目报告，站点，发布站点。

它们相互独立。也可以直接运行 mvn clean install site 运行所有这三套生命周期。

每套生命周期都由一组阶段(Phase)组成，我们平时在命令行输入的命令总会对应于一个特定的阶段。比如，运行 mvn clean，这个
clean 是 Clean 生命周期的一个阶段。有 Clean 生命周期，也有 clean 阶段。

5. Clean声明周期
   ① pre-clean 执行一些需要在clean之前完成的工作
   ② clean 移除所有上一次构建生成的文件
   ③ post-clean 执行一些需要在clean 之后立刻完成的工作
6. 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 将最终的包复制到远程的仓库，以让其它开发人员与项目共享或部署到服务器上运行。
7. Site生命周期
   ①pre-site 执行一些需要在生成站点文档之前完成的工作
   ②site 生成项目的站点文档
   ③post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
   ④site-deploy 将生成的站点文档部署到特定的服务器上

13. 继承

1. 现状
   Hello依赖的Junit：4.0
   HelloFriend依赖的Junit：4.0
   MakeFriends依赖的Junit：4.9

由于test范围的依赖不能传递，所以必然会分散在各个模块工程中，很容易造成版本不一致。

2. 需求：统一管理各个模块工程中对Junit依赖的版本。

3. 解决思路：将Junit依赖统一提取到“父”工程中，在子工程中声明Junit依赖是不指定版本，以父工程中统一设定的为准。同时也便于修改。

4. 操作步骤：
   ① 创建一个Maven工程Parent作为父工程，打包方式为pom
   
   ② 在子工程中声明对父工程的引用
   
   ③ 将子工程的坐标中与父工程坐标中重复的内容删除
   ④ 在父工程中统一管理Junit的依赖
   
   ⑤ 在子工程中删除Junit依赖的版本号部分

14. 聚合

1. 为什么要使用聚合？
   将多个工程拆分为模块后，需要手动逐个安装到仓库后依赖才能够生效。 修改源码后也需要逐个手动进行 clean 操作。而使用了聚合之后就可以批量进行 Maven 工程的安装、清理工作。
2. 配置方式：在一个总的聚合工程中配置各个参与聚合的模块
   
3. 使用方式：在聚合工程的pom.xml 上点右键->run as->maven install
   

15. Maven 酷站

我们可以到http://mvnrepository.com/搜索需要的 jar 包的依赖信息。