Maven：自动化构建工具

Maven的出现是为了解决以下的问题：

---

• 一个项目就是一个工程，如果一个项目很庞大，用package来组织的项目不好管理。最好一个项目一个工程，利于分工管理。利用maven可以将一个项目拆分成多个工程。

• 项目中的jar包需要手动复制粘贴到WEB-INF/lib目录下

  带来的问题是：同样的jar包重复出现在不同的项目工程中，一方面浪费存储资源，另一方面，也让工程比较臃肿。借助maven，可以将jar包仅仅保存在仓库中，有需要使用的工程引用这个文件接口，并不需要真的把jar包复制过来。

• jar包需要别人为我们准备好，或者自己到官网下载

  • 不同技术的官网提供jar包下载的形式五花八门。

  • 还有一些技术的官网就是通过maven或者svn等专门的工具来提供下载的。

  • 通过不规范的方式下载的jar包，那么其中的内容也可能是不规范的。

  • 借助于Maven可以以一种规范的方式下载jar包，因为所有知名框架或者第三方工具的jar包已经按照统一的规范存放在了Maven的中央仓库中

  • 以规范的方式下载的jar包，内容也是规范的

    Tips：统一规范对整个人类社会的发展是很重要的

• 一个jar包依赖的其他jar包需要自己手动加入到项目中

  • 如果所有jar包之间的依赖关系都需要程序员自己非常的清楚了解，那么就会极大的增加学习成本。

  • Maven会自动将被依赖的jar包导入进来。

Maven是什么

---

• Maven是一款服务于java平台的自动化构建工具。Make--》Ant--》Maven--》Gradle

• 构建

  【1】概念：以“java源文件”、“框架配置文件”、“JSP”、“HTML”、“图片”等资源为“原材料”，去“生产”一个可以运行的项目的过程。

  【2】编译：Java源文件（.java）--》编译--》class字节码文件（.calss）--》交给JVM去执行

  【3】部署：一个BS项目最终运行的并不是动态web工程本身，而是这个动态web工程变异的结果。

  ​ 生的鸡---》处理---》熟的鸡

  ​ 动态web工程--》编译、部署--》编译结果

  【4】运行时环境：其实是一组jar包的引用，并没有把jar包本身复制到工程中，所以并不是目录。

注意：开发过程中，所有的路径或配置文件中配置的类路径都是以编译结果的目录结构为标准的。

day：20200303

1、构建过程中的各个环节

【1】清理：将以前编译得到的旧的class文件删除，为下一次编译做准备

【2】编译：将java源程序编码成class字节码文件

【3】测试：自动测试，自动调用JUnit程序

【4】报告：测试程序执行的成果

【5】打包：动态web工程打war包，java工程打jar包

【6】安装：Maven的特定的概念----将打包得到的文件复制到“仓库”中指定的位置。

【7】部署：将动态web工程生成的war包复制到servlet容器的指定路径下，使其可以运行

2、安装Maven核心程序

【1】检查java 环境：echo %JAVA_HOME%

【2】解压Maven程序的核心程序的压缩包，放在一个非中文无空格路径下

【3】配置Maven环境变量MAVEN_HOME或M2_HOME，还有path

注意：配置M2_HOME可以避免MAVEN老版本可能出现的问题

3、Maven的核心概念

【1】约定的目录结构

【2】POM

【3】坐标

【4】依赖

【5】仓库

【6】生命周期、插件、目标

【7】继承

【8】聚合

4、第一个Maven工程

• 创建约定的目录结构

【1】根目录：工程名

【2】src目录：源码

【3】POM.xml：Maven工程的核心配置文件

【4】main目录：存放主程序

【5】test目录：存放测试程序

【6】java目录：存放java的源文件

【7】resource目录：存放框架或其他工具的配置文件

• 为什么要遵守规定的目录结构

  • maven要负责项目的自动化构建，以编译为例，Maven想要自动进行编译，那么它必须知道java源文件保存在哪里

  • 如果我们自己自定义的东西想让框架或者工具知道，那么就要符合框架或者工具的规则，有以下两种方式：

    • 以配置的方式明确告诉框架
    • 遵守框架内部已经存在的约定

  • 约定 > 配置 > 代码

• 配置文件示例

• Maven常用命令

  【1】mvn clean：清理

  【2】mvn compile： 编译主程序

  【3】mvn test-compile：编译测试程序

  【4】mvn test：执行测试

  【5】mvn package：打包

  【6】mvn install：安装

  【7】mvn site：生成站点

• 关于联网的问题

  • Maven的核心程序中仅仅定义了抽象的生命周期，但是具体的工作必须由特定的插件来完成。而插件本身并不包含在Maven的核心程序中
  • 当我们执行的maven命令需要用到某些插件时，Maven核心程序会首先到本地仓库中查找
  • 本地仓库的默认位置：【系统中当前用户的家目录】.m2\repository
  • Maven核心程序如果在本地仓库中找不到需要的插件，那么它会自动连接外网，到中央仓库下载。
  • 如果此时无法连接外网，那么就会构建失败
  • 修改默认本地仓库的位置可以让Maven核心程序到我们事先准备好的目录下去查找插件

• POM（Project Object Model ）项目对象模型

  扩展：DOM（Document Object Model）

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

• Maven坐标：使用三个向量在仓库中唯一定位一个Maven工程

  【1】groupid：公司或组织域名倒序+项目名

  【2】artifactid：模块名称

  【3】version：版本

• Maven工程的坐标与仓库中路径的对应关系

注意：版本号之后再将模块名和版本名拼接就是文件名称

• Maven仓库

  • 分类：

    【1】当前电脑上部署的仓库目录，为当前电脑上所有的Maven服务

    【2】远程仓库：私服、中央仓库、中央仓库的镜像

  • 仓库中保存的内容：Maven工程

    【1】Maven自身所需要的插件

    【2】第三方框架或工具的jar包

    【3】我们自己开发的Maven工程

• 依赖

  【1】Maven解析依赖时会到本地仓库中查找被依赖的jar包

  ​ 对于我们自己开发的Maven工程，执行install命令，项目就会打包进入Maven仓库

  【2】依赖的范围

  • compile范围依赖

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

  • test范围依赖

    • 对主程序是否有效：无效
    • 对测试程序是否有效：有效
    • 是否参与打包：不参与

  • provided

    • 对主程序是否有效：有效
    • 对测试程序是否有效：有效
    • 是否参与打包：不参与
    • 是否参与部署：不参与
    • 典型例子：servlet-api.jar

• 生命周期：

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

• 插件和目标

  【1】生命周期的各个阶段仅仅定义了要执行的任务是什么

  【2】各个阶段和插件的目标是对应的

  【3】相似的目标由特定的插件来完成

  【4】你可以将目标看做：调用插件功能的命令

day：20200304

• 在集成开发环境IDE中使用Maven

  Maven插件的设置

  【1】installations：指定Maven核心程序的位置。不建议使用插件自带的Maven程序

  【2】User Settings：指定settings的路径，进而获取本地仓库的位置

• Maven基本操作

  【1】创建Maven版的Java工程

  【2】创建Maven版本的额web工程

  【3】执行Maven命令

• 指定项目使用的java版本

• 依赖（高阶）

  • 依赖的传递性

好处：可以传递的依赖不必在每个模块工程中都重复声明，在“最下面”的工程中依赖一次即可

【注意】：非compile范围的依赖不能传递。所以在各个工程模块中，如果有需要就得重复声明依赖

• 依赖的排除

  【1】需要设置依赖排除的场合：

【2】用法，在相关的依赖中添加Exclusions

• 依赖的原则

  【1】作用：解决模块工程之间的jar包冲突问题

  【2】情景设定1：验证路径最短者优先的原则

  

  【3】情景设定2：验证路径相同时先声明者优先

• 统一管理依赖的版本

  【1】情景举例：

​ 这里对Spring各个jar包的依赖版本都是4.0.0，如果要统一升级版本为4.1.1，该怎么操作?

​ 手动修改，会导致遗漏问题

【2】建议配置方式

​ i.使用properties标签内使用自定义标签统一声明版本号

​ ii.在需要统一版本的位置，使用以下的方式

• 继承

  【1】现状：test域中的依赖是不能传递的，必然会分散在各个模块中，容易造成版本不一致的问题，那么我们该如何对依赖进行版本管理呢？

  • Hello依赖的JUnit版本：4.0
  • HelloFriend依赖的JUnit版本：4.0
  • MakeFriends依赖的JUnit版本：4.9

  【2】需求：统一管理各个模块功能中对JUnit依赖的版本

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

  【4】操作步骤：

  ​ a。创建一个Maven工程作为父工程。注意：打包的方式为POM

​ b。在子工程中声明对父工程的引用

​ c。将子工程的坐标中与父工程坐标中重复的内容删掉

​ d。在父工程中统一JUnit依赖的版本

​ e。在子工程中删除JUnit依赖的

注意：配置继承后，执行安装命令时要先安装父工程

• 聚合：

  • 作用：一键安装各种模块工程

  • 配置方式：在一个“总的聚合工程”中，配置各个参与聚合的模块

• 使用方式：在聚合工程的pom.xml上右键--》run as --》maven install

• Maven的自动部署

2020-03-04 学习完毕 bilibili