Maven[尚硅谷] Summary after videos

一、Maven简介

1.1 Maven的需求

目前技术在开发中存在的问题：
- 一个项目就是一个工程：如果项目非常庞大，就不适合继续使用package来划分模块。最好是每一个模块对应一个工程，利于分工协作。借助于Maven就可以将一个项目拆分成多个工程。
- 项目中的jar包必须手动复制、粘贴到WEB-INF/lib目录下：带来的问题是同样的jar包文件重复出现在不同的项目工程中，一方面浪费存储空间，另外也让工程比较臃肿。借助Maven，可以将jar包仅仅保存在“仓库”中，有需要使用的工程”引用”这个文件接口，并不需要真的把jar包复制过来。
- jar包需要别人替我们准备好，或到官网下载：不同技术的官网提供jar包下载的形式不同。有些技术的官网就是通过Maven或SVN等专门的工具来提供下载的。如果是以不规范的方式下载的jar包，那么其中的内容很可能也是不规范的。借助于Maven可以以一种规范的方式下载jar包。因为所有知名框架或第三方工具的jar包以及按照统一的规范存放在了Maven的中央仓库中。以规范的方式下载的jar包，内容也是可靠的。
- 一个jar包依赖的其他jar包需要自己手动加入到项目中：如果所有jar包之间的依赖关系都需要程序员自己非常清楚的了解，那么就会极大的增加学习成本。Maven会自动将被依赖的jar包导入进来。

1.2 Maven的概述

Maven是Apache软件基金会组织维护的一款自动化构建工具。主要有两个作用:
- maven工程对jar包的管理过程。
- 项目的一键构建。
构建：以java原文件、框架配置文件、JSP、HTML、图片等资源为原材料，去生产一个可以运行的项目过程，其中包括：编译、部署、搭建。
- 编译：Java源文件->编译->Class字节码文件->交给JVM去执行。
- 部署：一个BS项目最终运行的并不是动态Web工程本身，而是这个动态Web工程编译的结果。
图解编译结果与动态Web工程的区别如下。

开发过程中，所有的路径或配置文件中配置的类路径等都是以编译结果的目录结构为标准的。
构建过程的各个环节：
- 清理：将以前编译得到的旧的class字节码文件删除，为下一次编译做准备。
- 编译：将Java源程序编程成class字节码文件。
- 测试：自动测试，自动调用junit程序。
- 报告：测试程序执行的结果。
- 打包：动态Web工程打war包，Java工程打jar包。
- 安装：Maven特定的概念一将打包得到的文件复制到 “仓库”中的指定位置。
- 部署：将动态Web工程生成的war包复制到Servlet容器的指定目录下，使其可以运行。

1.3 安装Maven核心程序

检查JAVA_HOME环境变量，maven本身就是java写的，所以要求必须安装JDK。
下载并解压 maven 安装程序，放在一个非中文无空格路径下。
配置Maven相关的环境变量。
证是否安装成功，在cmd中运行mvn -v命令。

1.4 第一个Maven工程(原生Maven)

手动创建时为什么要遵守约定的目录结构？Maven要负责我们这个项目的自动化构建，以编译为例，Maven要想自动进行编译，那么它必须知道Java源文件保存在哪里。而我们自定义的东西要想让框架知道或工具知道，有两种方式：
- 通过配置的方式告诉框架。
- 按照框架约定的来创建。
编写pom.xml。

在src/main/java/com/atguigu/maven目录下新建文件Hello.java。

在/src/test/java/com/atguigu/maven目录下新建测试文件HelloTest.java。

在命令行中运行基本命令：
- mvn compile：编译。
- mvn clean：清理。
- mvn test：测试。
- mvn package：打包。
运行Maven命令时一定要进入pom.xml文件所在的目录。

二、Maven核心概念

2.1 Maven目录结构

2.2 Maven常用命令

mvn clean：将target目录删除，但是已经install到仓库里的包不会删除。
mvn compile：编译主程序。
mvn test-compile：编译测试程序。
mvn test：执行测试。
mvn package：打包。
mvn install：安装。
mvn deploy：部署、生成站点。

2.3 maven工程对jar包的管理过程

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

2.4 POM

POM：Project Object Model，项目对象模型。
DOM：Document Object Model，文档对象模型。
pom.xml对于Maven工程是核心配置文件，与构建过程相关的一切设置都在这个文件中进行配置。重要程度相当于web.xml对于动态Web工程。

2.5 坐标

Maven的坐标，使用三个向量在仓库中唯一定位一个Maven工程：
- groupid：公司或组织域名的倒序+项目名，com.baidu.projectname。
- artifactid：模块名。
- version：版本。
Maven工程的坐标与仓库中路径的对应关系。

2.6 仓库

仓库的分类：
- 本地仓库：当前电脑上部署的仓库目录，为当前电脑上的Maven工程服务。
- 远程仓库：
  - 私服：搭建在局域网环境中，为局域网范围内的所有Maven工程服务。
  - 中央仓库：架设在Internet上，为全世界所有Maven工程服务。
  - 中央仓库镜像：为了分担中央仓库的流量,提升用户访问速度。
- 仓库中保存的内容：Maven工程。
  - Maven自身所需的插件。
  - 第三方框架或工具的jar包。
  - 自己开发的Maven工程。

2.7 依赖

Maven解析依赖信息时会到本地仓库中查找被依赖的jar包。对于我们自己开发的Maven工程，使用mvn install命令安装后就可以进入仓库。

compile范围依赖：
- 对主程序是否有效：有效。
- 对测试程序是否有效：有效。
- 是否参与打包：参与。
- 是否参与部署：参与。
- 典型例子：spring-core。
test范围依赖：
- 对主程序是否有效：无效。
- 对测试程序是否有效：有效。
- 是否参与打包：不参与。
- 是否参与部署：不参与。
- 典型例子：junit。
provided范围依赖：
- 对主程序是否有效：有效。
- 对测试程序是否有效：有效。
- 是否参与打包：不参与。
- 是否参与部署：不参与。
- 典型例子：servlet-api.jar。

依赖的传递性。

好处：可以传递的依赖不必在每个模块工程中都重复声明。注意：非compile范围的依赖不能传递。所以在各个工程模块中，如果有需要就得重复声明依赖。
依赖排除的设置方式如下。

依赖的原则：
- 作用：解决模块工程之间的jar包冲突问题。
- 情景设定一：验证路径最短者优先原则。
- 情景设定二：验证路径相同时先声明者优先。

统一管理依赖的版本：
- 这里需要对spring各个jar包的依赖版本进行管理，如需要升级到4.1.1。
- 配置方式如下。
使用properties标签内使用自定义标签统一声明版本号。

在需要统一版本的位置，使用${自定义标签名}引用声明的版本号。

其实properties标签配合自定义标签声明数据的配置并不是只能用于声明依赖的版本号。凡是需要统一声明后再引用的场合都可以使用。

2.8 生命周期

各个构建环节执行的顺序，不能打乱顺序，必须按照既定的正确顺序来执行。
Maven的核心程序中定义了抽象的生命周期，生命周期中各个阶段的具体任务是由插件来完成的。
Maven核心程序为了更好的实现自动化构建，按照这一的特点执行生命周期中的各个阶段：不论现在要执行生命周期中的哪一个阶段，都是从这个生命周期最初的位置开始执行。