Maven 基本使用笔记-CSDN博客

本文链接：https://blog.csdn.net/darkpumpkin/article/details/135747525

本文是看了B站上的尚硅谷maven视频后结合csdn上学习笔记进一步整理得到的，有助于结合视频系统化入门maven。下图为maven的学习路线：

官网：http://maven.apache.org/

教程：https://www.yiibai.com/maven/

Maven库：http://repo2.maven.org/maven2/

Maven 酷站（ jar 包的依赖信息）：http://mvnrepository.com/

中央仓库资源：

http://mvnrepository.com/

https://search.maven.org/

1.maven使用的必要性（现有开发过程中存在的问题）

1）一个项目就是一个工程。

如果说项目组织非常庞大，那么项目十分臃肿，不适合用package划分模块，我们希望一个模块对应一个工程，每个人负责自己的模块，分工协作。

借助maven可以将一个项目拆分成多个工程。

2）项目中需要的jar包需要手动“复制”，“粘贴”到WEB-INF/lib目录下。

每一个项目需要相同的jar包，jar包会被重复包含到每一个项目。那么被大量项目重复使用的jar包会占用存储空间，浪费重复空间。

maven引用jar包，使得重复被使用的jar包只有一份，节省了存储资源。

3）jar包需要别人手动准备好，或者是到官网下载。

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

有些技术的官网就是通过maven或者svn来提供下载的。

如果是通过不正规途径下载的jar包，可能内容也不规范。

maven可以通过“统一的规范”正规下载jar包，这些jar包被放在了maven的中央仓库中。

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

maven其实本质上封装了jar包之间的依赖关系，程序员只需要引用所需要的jar包就可以了。

2.maven是什么

1）maven是一款服务于java平台的自动化构建工具。

构建工具发展：Make-》Ant-》Maven-》Gradle。

2)构建

【1】概念：以一系列的资源去生产一个可运行的项目。

编译、部署、搭建。

【2】编译：java源文件—编译—》Class字节码文件。

【3】部署：一个BS项目最终运行的不是动态Web工程本身，而是这个工程“编译过后的结果”。

web工程的目录和最终工程编译后的结果目录是不一致的。

3）构建过程中的各个环节

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

【2】编译：将java文件编译得到class文件。

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

【4】报告：报告测试结果。

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

【6】安装：将打包过后的项目复制到仓库中的指定位置。

【7】部署：将动态Web程序生成的war包复制到servlet容器下的指定目录，使其可以运行。

3.maven的核心概念

1）约定的目录结构

为什么要使用约定的目录结构？

因为maven需要知道jave源代码位置进行自动编译，只能按照框架的约定。

个人在新建maven项目中遇到的问题，项目新建成功后没有生成约定（src）目录。

解决方法：https://blog.csdn.net/weixin_42479293/article/details/91418502

在项目配置中需要加archetypeCatalog=internal

2）POM

【1】含义：Project Object Module项目对象模型

【2】pom.xml是项目的核心配置文件

3）坐标（gav）

【1】groupId：公司或者组织域名+项目名

【2】artifactId：模块名称

【3】version：版本

【4】坐标和仓库路径的对应关系

坐标示例：

< 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

4）依赖

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

对于我们自己开发的maven工程，使用install安装后就可以进入仓库。

【2】依赖范围

compile范围依赖

》对主程序是否有效：有效

》对测试程序是否有效：有效

》是否参与打包：参与

》是否参与部署：参与

》典型例子：spring-core

test范围依赖

》对主程序是否有效：无效

》对测试程序是否有效：有效

》是否参与打包：不参与

》是否参与部署：不参与

》典型例子：Junit

provided范围依赖

》对主程序是否有效：有效

》对测试程序是否有效：有效

》是否参与打包：不参与

》是否参与部署：不参与

》典型例子：Servlet-api.jar

【3】依赖的传递性

优点：可以传递的依赖不用重复申明。

注意：只有compile范围的才能被传递，test和provided范围的在引用和被引用的模块之间都是相互独立的。

【4】依赖的排除

》情景：如果我们当前工程中引入A，A依赖于B，而B的版本不太稳定，我们不希望B对我们的项目造成影响，我们可以在引入A的时候将B排除。

》配置方式

<dependency>
<groupId>com.atguigu.maven</groupId>
<artifactId>HelloFriend</artifactId>
<version>0.0.1-SNAPSHOT</version>
<type>jar</type>
<scope>compile</scope>
<exclusions>
    < exclusion>
        <groupId>commons-logging</groupId>
        <artifactId>commons-logging</artifactId>
    </ exclusion> 
</exclusions>
</dependency>

》排除后的效果

【5】依赖的原则：解决jar包冲突

》路径最短者优先

》路径相同时先申明者优先（dependency申明的顺序决定）

5）仓库

【1】仓库分类

》本地仓库：电脑本地目录下的仓库，为本地maven工程服务。

》远程仓库：

私服：搭建在局域网环境中，为局域网范围内的所有maven工程服务。
中央仓库：架设在Internet上，为全世界的maven工程服务。
中央仓库镜像：为了分担中央仓库的流量，分担仓库访问压力

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

》maven自身所需要的插件

》第三方框架或工具的jar包

》我们自己开发的maven工程

【3】构建项目中依赖包下载的流程

》从本地资源库中查找并获得依赖包，如果没有，执行第2步。

》从Maven默认中央仓库中查找并获得依赖包（http://repo1.maven.org/maven2/），如果没有，执行第3步。

》如果在pom.xml中定义了自定义的远程仓库，那么也会在这里的仓库中进行查找并获得依赖包，如果都没有找到，那么Maven就会抛出异常。

【4】使用阿里云镜像仓库遇到的问题（Https证书安全检查问题）

https://blog.csdn.net/ll837448792/article/details/105902014/

6）生命周期/插件/目标

【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】插件和目标

Maven的核心仅仅定义了抽象的声明周期，具体的任务都是交由插件完成的。

每个插件都实现多个功能，每个功能就是一个插件目标。

Maven的生命周期与插件目标相互绑定，以完成某个具体的构建任务。

可以将目标看做“调用插件功能的命令”。

例如：compile 就是插件 maven-compiler-plugin 的一个目标；pre-clean 是插件 maven-clean-plugin 的一个目标。

7）继承

【1】现状：由于test范围的依赖不能传递，所以造成各个版本模块中版本不一致。

【2】需求：统一各个模块工程中对junit依赖的版本。

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

【4】操作步骤：

》创建一个Maven工程作为父工程，以pom方式进行打包

<groupId>com.xxy</groupId>
<artifactId>Parent</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom</packaging>

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

<parent>
    <groupId>com.xxy</groupId>
    <artifactId>Parent</artifactId>
    <version>1.0-SNAPSHOT</version>
<!--    相对路径-->
    <relativePath>../Parent/pom.xml</relativePath>
  </parent>

》将子工程与父工程重复的内容删除（将junit部分删除）

》在父工程中统一junit依赖

<dependencies>
  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.11</version>
    <scope>test</scope>
  </dependency>
</dependencies>

》在子工程删除junit依赖的版本号部分

8）聚合

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

相当于将多个mvn install各个模块转化为一个mvn install聚合工程。