工具- maven

1、maven的作用

管理庞大的jar包
在脱离IDE集成开发工具的环境下对项目进行构建。

2、maven是什么

maven是阿帕奇软件基金组织维护的一款专门为java项目提供构建和依赖管理支持的工具。

2.1、构建

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

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

2.2、依赖

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

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

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

3、根据坐标创建maven工程(java工程)

3.1、maven中的坐标

使用三个向量在maven仓库中唯一定位到一个jar包。

groupId：公司或组织的id，即公司或组织的域名的倒序，通常也会加上项目名称
artifactId：一个项目或者是项目中的一个模块的id
version：模块的版本号。SNAPSHOT表示快照版本，正在迭代的过程中，是不稳定的版本。RELEASE表示正式版本。

1
2
3

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

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

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

Maven本地仓库根目录是在settings.xml文件中配置的。我这里是D:\Java\maven\MavenRepository

jar包的文件名是以artifactId-版本号来命名的。

3.2、POM文件中标签详解

<!--modelVersion:从maven2.0开始就固定是4.0.0，表示当前pom。xml采用的标签结构 -->
<modelVersion>4.0.0</modelVersion>
  
<!-- 当前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标签：在Maven中定义属性值-->
  <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>

POM：Project Object Model，项目对象模型。和 POM 类似的是：DOM（Document Object Model），文档对象模型。它们都是模型化思想的具体体现。

< scope>

表示依赖范围。标签的可选值：compile/test/provided/system/runtime/import

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

test：测试过程中使用的 jar 包，以 test 范围依赖进来。比如 junit。

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

3.3、maven约定的目录结构

这个结构在超级POM文件中已经配置，我们自己的maven项目中的pom是子pom，。就不需要再配置了。

3.4、执行maven的构建命令（命令行）

mvn -v 命令和构建操作无关，只要正确配置了 PATH，在任何目录下执行都可以。而构建相关的命令要在 pom.xml 所在目录下运行——操作哪个工程，就进入这个工程的 pom.xml 目录。

清理操作

mvn clean，删除target目录
编译操作

mvn compile 主程序编译

测试程序编译：mvn test-compile

主体程序编译结果存放的目录：target/classes

测试程序编译结果存放的目录：target/test-classes
测试操作

mvn test 构建test目录下的代码

测试的报告(错误信息，成功信息)存放的目录：target/surefire-reports
打包操作

mvn package

打包的结果——jar 包(java工程)，存放的目录：target，jar包名字是artifitId-version.jar
安装操作

mvn install

安装的效果是将本地构建过程中生成的 jar 包存入 Maven 本地仓库。这个 jar 包在 Maven 仓库中的路径是根据它的坐标生成的。

另外，安装操作还会将 pom.xml 文件转换为 XXX.pom 文件一起存入本地仓库。所以我们在 Maven 的本地仓库中想看一个 jar 包原始的 pom.xml 文件时，查看对应 XXX.pom 文件即可，它们是名字发生了改变，本质上是同一个文件。

4、创建Maven版的web工程

首先创建一个maven项目。

main目录下缺少java、resources，src目录下缺少test目录，test目录下缺少java目录，添加上去

生成的pom.xml文件，多了一个build标签

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.vickkkyz</groupId>
  <artifactId>ssm_in</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>war</packaging>

  <name>ssm_in Maven Webapp</name>
  <!-- FIXME change it to the project's website -->
  <url>http://www.example.com</url>

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <maven.compiler.source>1.7</maven.compiler.source>
    <maven.compiler.target>1.7</maven.compiler.target>
  </properties>

  <dependencies>

    <!-- junit测试 -->
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.13.1</version>
    </dependency>

  </dependencies>

  <build>
    <finalName>ssm_in</finalName>
    <pluginManagement><!-- lock down plugins versions to avoid using Maven defaults (may be moved to parent pom) -->
      <plugins>
        <plugin>
          <artifactId>maven-clean-plugin</artifactId>
          <version>3.1.0</version>
        </plugin>
        <!-- see http://maven.apache.org/ref/current/maven-core/default-bindings.html#Plugin_bindings_for_war_packaging -->
        <plugin>
          <artifactId>maven-resources-plugin</artifactId>
          <version>3.0.2</version>
        </plugin>
        <plugin>
          <artifactId>maven-compiler-plugin</artifactId>
          <version>3.8.0</version>
        </plugin>
        <plugin>
          <artifactId>maven-surefire-plugin</artifactId>
          <version>2.22.1</version>
        </plugin>
        <plugin>
          <artifactId>maven-war-plugin</artifactId>
          <version>3.2.2</version>
        </plugin>
        <plugin>
          <artifactId>maven-install-plugin</artifactId>
          <version>2.5.2</version>
        </plugin>
        <plugin>
          <artifactId>maven-deploy-plugin</artifactId>
          <version>2.8.2</version>
        </plugin>
      </plugins>
    </pluginManagement>
  </build>
</project>

如果使用Servlet类，需要自己去导入servlet-api依赖。因为以前是配置了tomcat，那里面有这个api，但是现在没有配置tomcat，就需要导入这个依赖。然后将项目编译过之后，将target目录中的项目文件夹放到tomcat中，启动tomcat，就可以在浏览器直接访问链接了。

5、依赖的传递性

①概念

A 依赖 B，B 依赖 C，那么在 A 没有配置对 C 的依赖的情况下，A 里面能不能直接使用 C？

②传递的原则

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

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

6、依赖排除

当 A 依赖 B，B 依赖 C 而且 C 可以传递到 A 的时候，A 不想要 C，需要在 A 里面把 C 排除掉。而往往这种情况都是为了避免 jar 包之间的冲突。

<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>

在A工程中依赖的B工程中排除X-1.0.jar

7、继承

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

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

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

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

一个大型 project 下面，创建了很多个 module。
每一个 module 都需要配置自己的依赖信息。
使用同一个框架内的不同 jar 包，它们应该是同一个版本，所以整个项目中使用的框架版本需要统一。

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

①创建父工程

创建的过程和前面创建普通maven项目一样。

工程名称：pro03-maven-parent

工程创建好之后，要修改它的打包方式：

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

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

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

②创建模块工程

模块工程类似于 IDEA 中的 module，所以需要进入 pro03-maven-parent 工程的根目录，然后创建模块工程。

假设，我们创建三个模块工程：(就是在这个项目里创建三个模块)

③查看被添加新内容的父工程 pom.xml

下面 modules 和 module 标签是聚合功能的配置，在父工程的pom.xml文件中自动生成的。

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

④解读子工程的pom.xml

<!-- 使用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> -->

⑤在父工程中配置依赖的统一管理

即使在父工程中配置了对依赖的管理，子工程需要使用具体的依赖的话还是需要配置相关的依赖，只是不需要指定版本号了。父工程的作用就是统一版本号。

<!-- 使用dependencyManagement标签配置对依赖的管理 -->
<!-- 被管理的依赖并没有真正被引入到工程 -->
<dependencyManagement>
	<dependencies>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-core</artifactId>
			<version>4.0.0.RELEASE</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-beans</artifactId>
			<version>4.0.0.RELEASE</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-context</artifactId>
			<version>4.0.0.RELEASE</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-expression</artifactId>
			<version>4.0.0.RELEASE</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-aop</artifactId>
			<version>4.0.0.RELEASE</version>
		</dependency>
	</dependencies>
</dependencyManagement>

⑥在父工程中声明自定义属性

在父工程中，自定义标签名字。自定义标签子工程中也可以写。

标签名就是属性名，标签值就是属性值。

<!-- 通过自定义属性，统一指定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>

每个模块之间也可以进行依赖。但是注意不要产生循环依赖。即A模块依赖B模块，B模块也依赖A模块。

如何将项目推送远程库

http://heavy_code_industry.gitee.io/code_heavy_industry/pro008-Git/lecture/chapter05/verse03.html

8、maven的生命周期

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

在任何一个生命周期内部，执行任何一个具体环节的操作，都是从本周期最初的位置开始执行，直到指定的地方。

9、maven中的插件

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

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

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

10、maven的仓库

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

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

11、maven配置文件resources

一般数据库连接信息等等配置需要放在 Maven 约定目录结构中的 resources 目录，这个目录存放各种配置文件。

12、超级POM

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

有效 POM 英文翻译为 effective POM，它的概念是这样的——在 POM 的继承关系中，子 POM 可以覆盖父 POM 中的配置；如果子 POM 没有覆盖，那么父 POM 中的配置将会被继承。按照这个规则，继承关系中的所有 POM 叠加到一起，就得到了一个最终生效的 POM。显然 Maven 实际运行过程中，执行构建操作就是按照这个最终生效的 POM 来运行的。这个最终生效的 POM 就是有效 POM，英文叫effective POM。

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

超级 POM：所有 POM 默认继承，只是有直接和间接之分。
父 POM：这一层可能没有，可能有一层，也可能有很多层。
当前 pom.xml 配置的 POM：我们最多关注和最多使用的一层。
有效 POM：隐含的一层，但是实际上真正生效的一层。

14、build标签

在实际使用 Maven 的过程中，我们会发现 build 标签有时候有，有时候没，这是怎么回事呢？其实通过有效 POM 我们能够看到，build 标签的相关配置其实一直都在，只是在我们需要定制构建过程的时候才会通过配置 build 标签覆盖默认值或补充配置。这一点我们可以通过打印有效 POM 来看到。

所以本质上来说：我们配置的 build 标签都是对超级 POM 配置的叠加。那我们又为什么要在默认配置的基础上叠加呢？很简单，在默认配置无法满足需求的时候定制构建过程，需要我们在build标签中定制，这样在项目打包到服务器时就可以启动。

这里是对build标签的总结和应用：

http://heavy_code_industry.gitee.io/code_heavy_industry/pro002-maven/chapter09/verse04.html

本文参考：https://www.bilibili.com/video/BV12q4y147e4?p=149&vd_source=c1b40fa5b4df055a1cae36a0ac4e1d21

FrameWork

#总结 #maven

工具- maven

https://vickkkyz.fun/2022/09/10/Java/framework/maven/

作者

Vickkkyz

发布于

2022年9月10日

许可协议

中间件-nginx 上一篇

框架-mybatis 下一篇