Maven核心概念学习笔记

最新推荐文章于 2024-01-29 10:45:09 发布

AfterSum

最新推荐文章于 2024-01-29 10:45:09 发布

阅读量588

点赞数

分类专栏： Maven 文章标签： maven java jar

本文链接：https://blog.csdn.net/Qiuyuguohou/article/details/124675433

版权

Maven 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

Maven学习笔记

前言：此文章是根据尚硅谷Maven课程学习整理而来，仅供参考和复习。

第一章 Maven概述

Maven 是 Apache 软件基金会组织维护的一款专门为 Java 项目提供构建和依赖管理支持的工具。

1、构建

构建过程包含的主要的环节：

清理：删除上一次构建的结果，为下一次构建做好准备
编译：Java 源程序编译成 *.class 字节码文件
测试：运行提前准备好的测试程序
报告：针对刚才测试的结果生成一个全面的信息
打包
- Java工程：jar包
- Web工程：war包
安装：把一个 Maven 工程经过打包操作生成的 jar 包或 war 包存入 Maven 仓库
部署
- 部署 jar 包：把一个 jar 包部署到 Nexus 私服服务器上
- 部署 war 包：借助相关 Maven 插件（例如 cargo），将 war 包部署到 Tomcat 服务器上

2、依赖

如果 A 工程里面用到了 B 工程的类、接口、配置文件等等这样的资源，那么我们就可以说 A 依赖 B。

依赖管理中要解决的具体问题：

jar 包的下载：使用 Maven 之后，jar 包会从规范的远程仓库下载到本地
jar 包之间的依赖：通过依赖的传递性自动完成
jar 包之间的冲突：通过对依赖的配置进行调整，让某些jar包不会被导入

3、Maven 的工作机制

在这里插入图片描述

第二章 Maven 核心程序解压和配置

1、Maven 官网地址

首页：

Maven – Welcome to Apache Maven(opens new window)

下载页面：

Maven – Download Apache Maven

2、解压Maven核心程序

核心程序压缩包：apache-maven-3.8.4-bin.zip，解压到非中文、没有空格的目录。

在解压目录中，我们需要着重关注 Maven 的核心配置文件：conf/settings.xml

3、指定本地仓库

本地仓库默认值：用户家目录/.m2/repository。由于本地仓库的默认位置是在用户的家目录下，而家目录往往是在 C 盘，也就是系统盘。将来 Maven 仓库中 jar 包越来越多，仓库体积越来越大，可能会拖慢 C 盘运行速度，影响系统性能。所以建议将 Maven 的本地仓库放在其他盘符下。配置方式如下：

<!-- localRepository
| The path to the local repository maven will use to store artifacts.
|
| Default: ${user.home}/.m2/repository
<localRepository>/path/to/local/repo</localRepository>
-->
<localRepository>D:\maven-repository</localRepository>

记住：一定要把 localRepository 标签从注释中拿出来。

注意：本地仓库本身也需要使用一个非中文、没有空格的目录。

4、配置阿里云提供的镜像仓库

Maven 下载 jar 包默认访问境外的中央仓库，而国外网站速度很慢。

改成阿里云提供的镜像仓库，访问国内网站，可以让 Maven 下载 jar 包的时候速度更快。配置的方式是：

mirrors里面包含很多标签每一个标签都代表着一个镜像配置。

①将原有的例子配置注释掉

<!-- <mirror>
  <id>maven-default-http-blocker</id>
  <mirrorOf>external:http:*</mirrorOf>
  <name>Pseudo repository to mirror external repositories initially using HTTP.</name>
  <url>http://0.0.0.0/</url>
  <blocked>true</blocked>
</mirror> -->

②加入我们的配置

将下面 mirror 标签整体复制到 settings.xml 文件的 mirrors 标签的内部。

<mirror>
		<id>nexus-aliyun</id>
		<mirrorOf>central</mirrorOf>
		<name>Nexus aliyun</name>
		<url>http://maven.aliyun.com/nexus/content/groups/public</url>
	</mirror>

5、配置 Maven 工程的基础 JDK 版本

按照默认配置运行，Java 工程使用的默认 JDK 版本是 1.5，而我们熟悉和常用的是 JDK 1.8 版本。

修改配置的方式是：将 profile 标签整个复制到 settings.xml 文件的 profiles 标签内。

maven中的标签

用户可以通过配置指定不同操作系统的信息，实现不同操作系统做不同的构建。

<profile>
	  <id>jdk-1.8</id>
	  <activation>
		<activeByDefault>true</activeByDefault>
		<jdk>1.8</jdk>
	  </activation>
	  <properties>
		<maven.compiler.source>1.8</maven.compiler.source>
		<maven.compiler.target>1.8</maven.compiler.target>
		<maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>
	  </properties>
	</profile>

第三章使用 Maven：命令行环境

1、Maven 核心概念：坐标

①数学中的坐标

在这里插入图片描述

使用 x、y、z 三个**『向量』作为空间的坐标系，可以在『空间』中唯一的定位到一个『点』**。

②Maven中的坐标

1]向量说明

使用三个**『向量』在『Maven的仓库』中唯一的定位到一个『jar』**包。

groupId：公司或组织的 id
artifactId：一个项目或者是项目中的一个模块的 id
version：版本号

[2]三个向量的取值方式

groupId：公司或组织域名的倒序，通常也会加上项目名称，一个项目可能会包含多个模块；
- 例如：com.atguigu.maven
artifactId：模块的名称，将来作为 Maven 工程的工程名
version：模块的版本号，根据自己的需要设定
- 例如：SNAPSHOT 表示快照版本，正在迭代过程中，不稳定的版本
- 例如：RELEASE 表示正式版本

举例：

groupId：com.atguigu.maven
artifactId：pro01-atguigu-maven
version：1.0-SNAPSHOT

③坐标和仓库中 jar 包的存储路径之间的对应关系

<groupId>javax.servlet</groupId>
 <artifactId>servlet-api</artifactId>
 <version>2.5</version>

上面坐标对应的 jar 包在 Maven 本地仓库中的位置：

Maven本地仓库根目录\javax\servlet\servlet-api\2.5\servlet-api-2.5.jar

使用命令生成Maven工程

在这里插入图片描述

调整

Maven 默认生成的工程，对 **junit 依赖的是较低的 3.8.1 版本，**我们可以改成较适合的 4.12 版本。

<!-- 依赖信息配置 -->
<!-- dependencies复数标签：里面包含dependency单数标签 -->
<dependencies>
	<!-- dependency单数标签：配置一个具体的依赖 -->
	<dependency>
		<!-- 通过坐标来依赖其他jar包 -->
		<groupId>junit</groupId>
		<artifactId>junit</artifactId>
		<version>4.12</version>
		
		<!-- 依赖的范围 -->
		<scope>test</scope>
	</dependency>
</dependencies>

2、Maven核心概念：POM

①含义

POM：Project Object Model，项目对象模型。和 POM 类似的是：

DOM（Document Object Model），文档对象模型。它们都是模型化思想的具体体现。

②模型化思想

POM 表示将工程抽象为一个模型，再用程序中的对象来描述这个模型。这样我们就可以用程序来管理项目了。我们在开发过程中，最基本的做法就是将现实生活中的事物抽象为模型，然后封装模型相关的数据作为一个对象，这样就可以在程序中计算与现实事物相关的数据。

③对应的配置文件

POM 理念集中体现在 Maven 工程根目录下 pom.xml 这个配置文件中。所以这个 pom.xml 配置文件就是 Maven 工程的核心配置文件。其实学习 Maven 就是学这个文件怎么配置，各个配置有什么用

pom.xml 解读

 <!-- 当前Maven工程的坐标 -->
  <groupId>com.atguigu.maven</groupId>
  <artifactId>pro01-maven-java</artifactId>
  <version>1.0-SNAPSHOT</version>
  
  <!-- 当前Maven工程的打包方式，可选值有下面三种： -->
  <!-- jar：表示这个工程是一个Java工程  -->
  <!-- war：表示这个工程是一个Web工程 -->
  <!-- pom：表示这个工程是“管理其他工程”的工程 -->
  <packaging>jar</packaging>

  <name>pro01-maven-java</name>
  <url>http://maven.apache.org</url>

  <properties>
	<!-- 工程构建过程中读取源码时使用的字符集 -->
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <!-- 当前工程所依赖的jar包 -->
  <dependencies>
	<!-- 使用dependency配置一个具体的依赖 -->
    <dependency>
	
	  <!-- 在dependency标签内使用具体的坐标依赖我们需要的一个jar包 -->
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.12</version>
	  
	  <!-- scope标签配置依赖的范围 -->
      <scope>test</scope>
    </dependency>
  </dependencies>

3、Maven核心概念：约定的目录结构

①各个目录的作用

在这里插入图片描述

另外还有一个 target 目录专门存放构建操作输出的结果。

②约定目录结构的意义

Maven 为了让构建过程能够尽可能自动化完成，所以必须约定目录结构的作用。

例如：Maven 执行编译操作，必须先去 Java 源程序目录读取 Java 源代码，然后执行编译，最后把编译结果存放在 target 目录。

③约定大于配置

Maven 对于目录结构这个问题，没有采用配置的方式，而是基于约定。这样会让我们在开发过程中非常方便。如果每次创建 Maven 工程后，还需要针对各个目录的位置进行详细的配置，那肯定非常麻烦。

目前开发领域的技术发展趋势就是：约定大于配置，配置大于编码。

5、Maven 的构建命令

运行 Maven 中和构建操作相关的命令时，必须进入到 pom.xml 所在的目录。

如果没有在 pom.xml 所在的目录运行 Maven 的构建命令，那么会看到下面的错误信息：

The goal you specified requires a project to execute but there is no POM in this directory

mvn clean 删除 target 目录
主程序编译：mvn compile 存放的目录：target/classes
测试程序编译：mvn test-compile 存放的目录：target/test-classes
mvn test
mvn package 打包的结果——jar 包，存放的目录：target
mvn install 将本地构建过程中生成的 jar 包存入 Maven 本地仓库。这个 jar 包在 Maven 仓库中的路径是根据它的坐标生成的。
- 安装操作还会将 pom.xml 文件转换为 XXX.pom 文件一起存入本地仓库。所以我们在 Maven 的本地仓库中想看一个 jar 包原始的 pom.xml 文件时，查看对应 XXX.pom 文件即可，它们是名字发生了改变，本质上是同一个文件。

6、依赖的范围

标签的位置：dependencies/dependency/scope

标签的可选值：compile/test/provided/system/runtime/import

①compile 和 test 对比

在这里插入图片描述

②compile 和 provided 对比

在这里插入图片描述

③结论

compile：通常使用的第三方框架的 jar 包这样在项目实际运行时真正要用到的 jar 包都是以 compile 范围进行依赖的。比如 SSM 框架所需jar包。

**test：**测试过程中使用的 jar 包，以 test 范围依赖进来。比如 junit。通过test范围依赖的jar包不会放入war包。

provided：服务器已经存在，不需要再部署打包。

在开发过程中需要用到的服务器上的 jar 包通常以 provided 范围依赖进来。比如 servlet-api、jsp-api。而这个范围的 jar 包之所以不参与部署、不放进 war 包，就是避免和服务器上已有的同类 jar 包产生冲突，同时减轻服务器的负担。

7、依赖的传递性

传递的原则

在 A 依赖 B，B 依赖 C 的前提下，C 是否能够传递到 A，取决于 B 依赖 C 时使用的依赖范围。

B 依赖 C 时使用 compile 范围：可以传递
B 依赖 C 时使用 test 或 provided 范围：不能传递，所以需要这样的 jar 包时，就必须在需要的地方明确配置依赖才可以。

8、依赖的排除

1、概念

当 A 依赖 B，B 依赖 C 而且 C 可以传递到 A 的时候，A 不想要 C，需要在 A 里面把 C 排除掉，阻止某些 jar 包的传递。为了避免 jar 包之间的冲突。

在这里插入图片描述

2、配置方式

使用excludes标签配置依赖的排除；

<dependency>
	<groupId>com.atguigu.maven</groupId>
	<artifactId>pro01-maven-java</artifactId>
	<version>1.0-SNAPSHOT</version>
	<scope>compile</scope>
	<!-- 使用excludes标签配置依赖的排除	-->
	<exclusions>
		<!-- 在exclude标签中配置一个具体的排除 -->
		<exclusion>
			<!-- 指定要排除的依赖的坐标（不需要写version） -->
			<groupId>commons-logging</groupId>
			<artifactId>commons-logging</artifactId>
		</exclusion>
	</exclusions>
</dependency>

9、继承

1、概念

Maven工程之间，A 工程继承 B 工程

B 工程：父工程
A 工程：子工程

本质上是 A 工程的 pom.xml 中的配置继承了 B 工程中 pom.xml 的配置。

2、作用

在父工程中统一管理项目中的依赖信息，具体来说是管理依赖信息的版本。

它的背景是：

对一个比较大型的项目进行了模块拆分。
一个 project 下面，创建了很多个 module。
每一个 module 都需要配置自己的依赖信息。

它背后的需求是：

在每一个 module 中各自维护各自的依赖信息很容易发生出入，不易统一管理。
使用同一个框架内的不同 jar 包，它们应该是同一个版本，所以整个项目中使用的框架版本需要统一。
确定所需要的 jar 包组合（或者说依赖信息组合）需要经过长期摸索和反复调试，耗费很大精力总结。

通过在父工程中为整个项目维护依赖信息的组合既保证了整个项目使用规范、准确的 jar 包；又能够将以往的经验沉淀下来，节约时间和精力。

在这里插入图片描述

①创建父工程

只有打包方式为 pom 的 Maven 工程能够管理其他 Maven 工程。

打包方式为 pom 的 Maven 工程中不写业务代码，它是专门管理其他 Maven 工程的工程。

 <groupId>com.atguigu.maven</groupId>
  <artifactId>pro03-maven-parent</artifactId>
  <version>1.0-SNAPSHOT</version>

  <!-- 当前工程作为父工程，它要去管理子工程，所以打包方式必须是 pom -->
  <packaging>pom</packaging>

②父工程 pom.xml

modules 和 module 标签是聚合功能的配置

<modules>  
	<module>pro04-maven-module</module>
	<module>pro05-maven-module</module>
	<module>pro06-maven-module</module>
</modules>

③子工程的pom.xml

使用parent标签指定当前工程的父工程

子工程坐标中的groupId和version与父工程一致，那么可以省略

<!-- 使用parent标签指定当前工程的父工程 -->
<parent>
	<!-- 父工程的坐标 -->
	<groupId>com.atguigu.maven</groupId>
	<artifactId>pro03-maven-parent</artifactId>
	<version>1.0-SNAPSHOT</version>
</parent>

<!-- 子工程的坐标 -->
<!-- 如果子工程坐标中的groupId和version与父工程一致，那么可以省略 -->
<!-- <groupId>com.atguigu.maven</groupId> -->
<artifactId>pro04-maven-module</artifactId>
<!-- <version>1.0-SNAPSHOT</version> -->

④父工程中声明自定义属性

一处修改，处处生效

<!-- 通过自定义属性，统一指定Spring的版本 -->
<properties>
	<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
	
	<!-- 自定义标签，维护Spring版本数据 -->
	<atguigu.spring.version>4.3.6.RELEASE</atguigu.spring.version>
</properties>

在需要的地方使用${}的形式来引用自定义的属性名：

	<dependency>
				<groupId>org.springframework</groupId>
				<artifactId>spring-core</artifactId>
				<version>${atguigu.spring.version}</version>
			</dependency>

10、聚合

使用一个“总工程”将各个“模块工程”汇集起来，作为一个整体对应完整的项目。

项目：整体
模块：部分

从继承关系角度来看：

父工程
子工程

从聚合关系角度来看：

总工程
模块工程

第四章其他核心概念

1、生命周期

①作用

为了让构建过程自动化完成，Maven 设定了三个生命周期，生命周期中的每一个环节对应构建过程中的一个操作。

在这里插入图片描述

③特点

前面三个生命周期彼此是独立的。
在任何一个生命周期内部，执行任何一个具体环节的操作，都是从本周期最初的位置开始执行，直到指定的地方。（本节记住这句话就行了，其他的都不需要记）

Maven 之所以这么设计其实就是为了**提高构建过程的自动化程度：**让使用者只关心最终要干的即可，过程中的各个环节是自动执行的

2、插件和目标

①插件

Maven 的核心程序仅仅负责宏观调度，不做具体工作。具体工作都是由 Maven 插件完成的。例如：编译就是由 maven-compiler-plugin-3.1.jar 插件来执行的。

②目标

一个插件可以对应多个目标，而每一个目标都和生命周期中的某一个环节对应。

Default 生命周期中有 compile 和 test-compile 两个和编译相关的环节，这两个环节对应 compile 和 test-compile 两个目标，而这两个目标都是由 maven-compiler-plugin-3.1.jar 插件来执行的。

3、仓库

本地仓库：在当前电脑上，为电脑上所有 Maven 工程服务
远程仓库：需要联网
- 局域网：我们自己搭建的 Maven 私服，例如使用 Nexus 技术。
- Internet
  - 中央仓库
  - 镜像仓库：内容和中央仓库保持一致，但是能够分担中央仓库的负载，同时让用户能够就近访问提高下载速度，例如：Nexus aliyun

建议：不要中央仓库和阿里云镜像混用，否则 jar 包来源不纯，彼此冲突。

专门搜索 Maven 依赖信息的网站：https://mvnrepository.com/

4、POM 的四个层次

在这里插入图片描述

1、超级 POM

Maven 在构建过程中有很多默认的设定。例如：源文件存放的目录、测试源文件存放的目录、构建输出的目录……等等。但是其实这些要素也都是被 **Maven 定义过的。**定义的位置就是：超级 POM。

所以我们自己的 POM 即使没有明确指定一个父工程（父 POM），其实也默认继承了超级 POM。就好比一个 Java 类默认继承了 Object 类。

2、父 POM

和 Java 类一样，POM 之间其实也是单继承的。

3、有效 POM

有效 POM 英文翻译为 effective POM，它的概念是这样的——在 POM 的继承关系中，子 POM 可以覆盖父 POM 中的配置；如果子 POM 没有覆盖，那么父 POM 中的配置将会被继承。按照这个规则，继承关系中的所有 POM 叠加到一起，就得到了一个最终生效的 POM。

显然 Maven 实际运行过程中，执行构建操作就是按照这个最终生效的 POM 来运行的。这个最终生效的 POM 就是有效 POM，英文叫effective POM。

综上所述，平时我们使用和配置的 POM 其实大致是由四个层次组成的：