Maven的概念

Maven的概念

为什么要用Maven？

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

Maven是什么？

Maven是一款服务于Java平台的自动化构建工具。

自动化构建工具：Make——>Ant——>Maven——>Gradle

构建：以“Java源文件”、“框架的配置文件”、“JSP”、“HTML/CSS”、“图片”等资源为“原材料”去“生产”一个可以运行的项目的过程。

• 编译：Java源文件（User.java）——>编译——>Class字节码文件（User.class）——>交给JVM去执行
• 构建：以编写的Java代码、框架配置文件、国际化等资源文件、JSP与静态资源作为“原材料”，去“生产”出一个可以运行的项目的过程。
• 部署：一个BS项目最终运行的并不是动态Web工程本身，而是这个动态Web工程"编译的结果"，部署就是把项目拿到服务器指定目录下的过程。

下图的JRE System Library运行时环境，其实是一组jar包的引用，并没有把jar包本身赋值到工程中，所以并不是目录。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-A6b5JRgD-1622857103106)(E:\开发笔记\maven\image\运行时环境.jpg)]

下面是动态Web工程"编译的结果：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-W3rdkKfL-1622857103109)(E:\开发笔记\maven\image\编译后的工程目录结构.jpg)]

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

构建过程中的各个环节

1. 清理：将以前编译得到的旧的class文件删除，为下一次编译做准备
2. 编译：将Java源程序文件编译成class文件
3. 测试：自动测试，自动调用junit程序
4. 报告：测试程序执行的结果
5. 打包：动态web工程打的是war包，Java工程是jar包
6. 安装：Maven特定的概念————将打包得到的文件复制到“仓库”中指定位置
7. 部署：将动态web工程生成的war包复制到Servlet容器的制定目录下，使其可以运行

安装Maven核心程序

1. 配置JAVA_HOME环境变量

2. 解压Maven核心的压缩包

3. 配置MAVEN_HOME、PAHT环境变量

   MAVEN的核心概念

   1. 约定的目录结构
   2. POM
   3. 坐标
   4. 依赖
   5. 仓库
   6. 生命周期/插件/目标
   7. 继承
   8. 聚合

   MAVEN工程目录

   1. 创建约定的目录结构

      • 根目录：工程名

      • src目录：源码

      • pom.xml文件：Maven工程的核心配置文件

      • main目录：存放主程序

      • test目录：存放测试程序

      • java目录：存放java源文件

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

        

   2. 为什么要遵守约定的目录结构？

      • Maven要负责我们这个项目的自动化构建，以编译过程为例，Maven要想自动进行编译，那么它必须知道Java源文件保存在哪里。
      • 如果自己自定义的东西想要让框架或工具知道，有两种办法
        • 以配置的方式明确告诉框架
        • 遵守框架内部存在的约定

常用的Maven命令

注意：执行与构建过程相关的Maven命令，必须进入pom.xml所在的目录

常用的命令

1. mvn clean：清理
2. mvn compile：编译主程序
3. mvn test-compile：编译测试程序
4. mvn test：执行测试
5. mvn package：打包

关于联网的问题

1. Maven的核心程序仅仅定义了抽象的生命周期，但是具体的工作必须由特定的插件来完成，而插件本身本身并不包含在Mavaen 的核心程序中。

2. 当我们执行的Maven命令需要用到某些插件时，Maven核心程序会首先到本地仓库中查找

3. 本地仓库的位置：【系统用户目录.m2\repository】

   C:\Users\Keeper\.m2\repository

4. Maven核心程序如果在本地仓库找不到需要的插件，那么它会自动连接外网，到中央仓库下载。

5. 如果此时无法连接外网，则构建失败。

6. 修改默认本地仓库的位置可以让Maven核心程序到我们事先准备好的目录下查找插件

   1. 找到Maven解压目录\conf\settings.xml

   2. 将以下标签增加到settings.xml文件中

      Maven仓库目录路径

POM

含义：Project Object Model（项目对象模型）

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

坐标

1. 数学中的坐标：

   1. 在平面上使用X,Y两个向量可以唯一的平面中的任何一个点
   2. 在空间中使用X，Y，Z三个向量可以唯一的定位空间中的任何一个点

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

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

      com.atguigu.maven

   2. artifactid：模块名

      Hello

   3. version：版本

      1.1.0

3. 对应关系

   <groupId>io.projectreactor</groupId>
   <artifactId>reactor-core</artifactId>
   <version>3.1.8.RELEASE</version>
   <!--对应下面路径-->
   io/projectreactor/reactor-core/3.1.8.RELEASE/reactor-core-3.1.8.RELEASE.jar
   

   仓库

   仓库的分类：

   1. 本地仓库：当前电脑上为部署的仓库目录，为当前电脑上所有Maven工程服务
   2. 远程仓库
      1. 局域网（私服）：搭建在局域网环境中，为所有局域网中的Maven工程服务
      2. 中央仓库：架设在Internet上，为全世界所有Maven工程服务
      3. 中央仓库镜像：为了分担仓库的流量，提升用户访问的速度

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

   1. Maven自身所需要的插件
   2. 第三方框架或工具的jar包
   3. 自己开发的Maven工程

   依赖

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

         1. compile范围依赖

            1. 对主程序是否有效：有效
            2. 对测试程序是否有效：有效
            3. 是否参与打包：参与

         2. test范围依赖

            1. 对主程序是否有效：无效
            2. 对测试程序是否有效：有效
            3. 是否参与打包：不参与

         3. provided范围依赖

            1. 对主程序是否有效：有效
            2. 对测试程序是否有效：有效
            3. 是否参与打包：不参与

生命周期

1. 各个构建环节执行的顺序：不能打乱顺序，必须按照既定的正确顺序来执行。

2. Maven的核心程序中定义了抽象的生命周期，生命周期中各个阶段的具体任务是由插件完成的。

3. Maven核心程序为了更好的实现自动化构建，按照这样的特点执行声明周期的各个阶段：不论现在要执行生命周期的哪一个阶段，都是从这个声明周期最初的位置开始执行。

   3. 是否参与打包：不参与

生命周期

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

依赖

1. 依赖的传递性：

• 好处：可以传递的依赖不必在每个模块工程中都重复声明，在“最下面”的工程依赖一次即可。
• 注意：非compile范围的依赖不能传递，所以在各个模块中，如果有需要就得重复声明这个依赖

2. 依赖的排除

• 需要设置排除的场合
• 依赖排除的设置方式
  

3. 依赖的原则

• 作用：解决模块工程之间的jar包冲突的问题
• 情景设置1：路径最短者优先原则
  
• 情景设定2： 路径相同时先声明者优先（dependency标签的声明顺序）
  

4. 统一管理依赖的版本
   -
   这里对spring各个jar包的依赖版本都是4.0，如何统一升级为4.1.1？

• 使用properties标签内使用自动以标签统一声明版本号

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

继承

现状

1. Hello依赖的junit：4.0
2. HelloFirend依赖的junit：4.0
3. MakerFriends依赖的junit：4.9
   由于test范围的依赖不能传递，所以必然会分散在各个模块工程中，很容易造成版本不一致

需求

统一管理模块工程中对junit依赖的版本

解决思路

将junit依赖版本统一提取到“父”工程中，在子工程中声明junit依赖时不指定版本，以父工程统一设定的为准，同时便于修改。

操作步骤

1. 创建一个Maven工程作为父工程，注意：打包的方式为pom

2. 在子工程中声明对父工程的引用

3. 将子工程的坐标中与父工程坐标中重复内容删除（黄线部分）

4. 在父工程中统一管理junit依赖

5. 在子工程中删除junit依赖的版本号部分

聚合

作用

一建安装各个模块工程

配置方式

在一个“总的聚合工程”中配置各个参与聚合的模块

使用方式

在聚合工程的pom.xml上点击右键——>run as——>maven install