Maven基础

Maven相关概念

构建

构建指的是使用 “原材料生产产品” 的过程

原材料	java源代码、图片、配置文件、…
产品	一个可以在服务器上运行的项目

构建包含的主要环节

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

构建工程图

依赖

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

• 例如：junit-4.12.jar包 依赖 hamcrest-core-1.3.jar包，想要使用junit包，就必须同时导入hamcrest-core包

依赖管理要解决的问题：

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

Maven用途

作为依赖管理工具

• 随着项目使用框架，导入的jar包会越来越多，且相互耦合关系也越复杂，已不可能使用人工管理
• Maven作为依赖管理工具，可以通过简单的配置，引入和管理jar包及其子jar包

作为构建工具

• JavaWeb程序必须要构建

• 当我们使用IDEA开发的时候，构建操作是IDEA替我们做的

• 在服务器环境上，没有IDEA这种图形化操作软件，但仍需要构建操作，可以用Maven

Maven的工作机制

Maven使用-1-Maven软件的解压与配置

步骤1：下载

下载地址

步骤2：解压Maven核心程序

解压到非中文、没有空格的目录

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

步骤3：指定本地仓库

本地仓库默认值：用户根目录/.m2/repository

• 由于本地仓库的默认位置是在用户的根目录下，而根目录往往是在 C 盘，也就是系统盘

• 将来 Maven 仓库中 jar 包越来越多，仓库体积越来越大，可能会拖慢 C 盘运行速度，影响系统性能

• 建议将 Maven 的本地仓库放在其他盘符下

指定本地仓库地址（conf/settings.xml文件）

<!-- 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:/GSF_Software/Web_Repository/Local</localRepository>

• 本地仓库这个目录，我们手动创建一个空的目录即可。

• 一定要把 localRepository 标签从注释中拿出来。

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

步骤4：配置阿里云提供的镜像仓库

Maven 下载的 jar 包默认访问境外的中央仓库，而国外网站速度很慢。改成阿里云提供的镜像仓库，访问国内网站，可以让Maven下载 jar 包的时候速度更快

指定镜像国内仓库（conf/settings.xml文件）

<!--<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>
  <id>aliyunmaven</id>
  <mirrorOf>*</mirrorOf>
  <name>aliyun</name>
  <url>https://maven.aliyun.com/repository/public</url>
</mirror>

• 注释掉默认配置
• 加入阿里云镜像配置：将mirror 标签整体复制到 settings.xml 文件的 mirrors 标签的内部

步骤5：配置 Maven工程的基础JDK版本

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

修改默认JDK版本配置：将 profile 标签整个复制到 settings.xml 文件的 profiles 标签内。

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

步骤6：配置环境变量

文章参考

Maven使用-2-命令行操作-创建jar工程

jar工程-根据坐标创建Maven版的Java工程

坐标-理解

概念	理解
数学中的坐标	(x, y, z) 定位空间中唯一一个点
Maven中的坐标	[groupId, artifactId, version] 定位Maven仓库中特定的jar包

坐标-Maven坐标的取值

坐标	取值	示例
groupId	公司或组织域名的倒序，通常也会加上项目名称	com.atguigu.maven
artifactId	模块的名称，将来作为 Maven 工程的工程名	pro01-atguigu-maven
version	模块的版本号，根据自己的需要设定	1.0-SNAPSHOT（表示快照版本，正在迭代过程中，不稳定的版本）
		RELEASE（表示正式版本）

坐标-Maven坐标和仓库中 jar 包之间的对应关系

pom.xml配置文件中，jar包的参数：

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

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

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

Maven工程创建-创建步骤

步骤1：创建工作空间

就是Maven工程要创建到的目录

• 跟本地仓库是两回事，该工作空间要在本地仓库外面

D:\maven-workspace\space201026

步骤2：命令行进入该工作空间并创建

• win + R，cmd
• 更改路径
• 运行创建命令：mvn archetype:generate

• 执行创建命令后有部分人工输入的操作

......
下载过程
......
Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): 7:【直接回车，使用默认值】

Define value for property 'groupId': com.atguigu.maven【输入groupId】

Define value for property 'artifactId': pro01-maven-java【输入artifactId】

Define value for property 'version' 1.0-SNAPSHOT: :【直接回车，使用默认值】

Define value for property 'package' com.atguigu.maven: :【直接回车，使用默认值】

Confirm properties configuration: groupId: com.atguigu.maven artifactId: pro01-maven-java version: 1.0-SNAPSHOT package: com.atguigu.maven Y: :【直接回车，表示确认。如果前面有输入错误，想要重新输入，则输入 N 再回车。】

Maven工程创建-调整

1、junit调整

用于提供工程的测试代码依赖

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

• 因为4.xx版本之后，才能使用注解

进入创建工程的pom.xml文件中：

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

2、自动生成的 App.java 和 AppTest.java 可以删除

Maven工程创建-pom.xml文件解读

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

    <!-- 当前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>
    
</project>

Maven核心概念-POM

含义

POM：Project Object Model，项目对象模型

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

模型化思想

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

配置文件

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

Maven核心概念-约定的Java工程目录结构

pro01-maven-java
	src【文件夹，源码目录】
		main【文件夹，主体程序目录】
			java【文件夹，java源代码】
				com【相关包】
			resources【文件夹，存放配置文件】
		test【文件夹，测试程序目录】
			java【文件夹，java源代码】
				com【相关包】
			resources【文件夹，存放配置文件】
	target【文件夹，通过命令生成，专门存放构建操作输出的结果】
	
	pom.xml【文件，配置文件】

约定的意义

Maven 为了让构建过程能够尽可能自动化完成，所以必须约定目录结构的作用。例如：Maven 执行编译操作，必须先去 Java 源程序目录读取 Java 源代码，然后执行编译，最后把编译结果存放在 target 目录。

技术理念：约定大于配置

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

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

• 最开始编程，一切通过代码解决
• 后来有了框架，开始引入配置信息
• 再后来封装的更高，用约定的形式来简化配置

jar工程-在Maven创建的Java工程中编写代码

主体程序

要被测试的程序

package com.atguigu.maven;
	
public class Calculator {
	
	public int sum(int i, int j){
		return i + j;
	}	
}

测试程序

测试主体程序的程序

package com.atguigu.maven;
	
import org.junit.Test;
import com.atguigu.maven.Calculator;
	
// 静态导入的效果是将Assert类中的静态资源导入当前类
// 这样一来，在当前类中就可以直接使用Assert类中的静态资源，不需要写类名
import static org.junit.Assert.*;
	
public class CalculatorTest{
	
	@Test
	public void testSum(){
		
		// 1.创建Calculator对象
		Calculator calculator = new Calculator();
		
		// 2.调用Calculator对象的方法，获取到程序运行实际的结果
		int actualResult = calculator.sum(5, 3);
		
		// 3.声明一个变量，表示程序运行期待的结果
		int expectedResult = 8;
		
		// 4.使用断言来判断实际结果和期待结果是否一致
		// 如果一致：测试通过，不会抛出异常
		// 如果不一致：抛出异常，测试失败
		assertEquals(expectedResult, actualResult);
	}
}

jar工程-执行Maven构建命令

构建准备-进入pom.xml所在目录

在非pom.xml目录下，是不能执行构建命令的

构建操作-相关命令

命令	操作	解释
mvn clean	删除 target 目录	可以在执行其他命令前执行该命令，确保所有构建数据都是该次构建产生的
mvn compile	主程序编译	主体程序编译结果存放的目录：target/classes
mvn test-compile	测试程序编译	测试程序编译结果存放的目录：target/test-classes
mvn test	进行测试	测试的报告存放的目录：target/surefire-reports
mvn package	打包操作	java工程，打包为：jar 包；JavaWeb工程，打包为：war包。存放的目录：target/
mvn install	安装操作	将本地构建过程中生成的 jar包/war包 存入 Maven 本地仓库，根据Maven坐标找寻对应位置
		该操作也会将pom.xml文件相应打包，名字变了，内容没变

Maven使用-3-命令行操作-创建war工程

war工程-创建Maven版的JavaWeb工程

JavaWeb工程目录结构

使用 mvn archetype:generate 命令生成 Web 工程时，需要使用一个专门的 archetype，其工程结构如下：

project
	- pom.xml
	- src
		-main
			- webapp
				- WEB-INF
					- web.xml
				- index.jsp
			- java【自己补充的，约定的目录结构，是构建命令构建出来就有的的标准结构】
				- 放置java的package包

构建操作

步骤1：路径准备

进入到工作空间中

步骤2：命令执行

mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-webapp -DarchetypeVersion=1.4

• 需要人工确定的步骤

......
文件下载
......

Define value for property 'groupId': com.atguigu.maven【手动输入】
Define value for property 'artifactId': pro02-maven-web【手动输入】
Define value for property 'version' 1.0-SNAPSHOT: :【直接回车，使用默认值】

Define value for property 'package' com.atguigu.maven: :【直接回车，使用默认值】
Confirm properties configuration: groupId: com.atguigu.maven artifactId: pro02-maven-web version: 1.0-SNAPSHOT package: com.atguigu.maven Y: :【直接回车，表示确认】

war工程-在Maven创建的JavaWeb工程中编写代码

后端编写：Servlet

步骤1：创建java目录，并创建servlet所在包的目录

• 两个框的内容都是手动创建的
• 红框：放入java package包的顶级目录
• 黑框，具体的一个java package包

步骤2：创建servlet类

package com.atguigu.maven;
	
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.ServletException;
import java.io.IOException;
	
public class HelloServlet extends HttpServlet{
	
	protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		
		response.getWriter().write("hello maven web");
		
	}	
}

步骤3：web.xml中注册servlet

  <servlet>
	<servlet-name>helloServlet</servlet-name>
	<servlet-class>com.atguigu.maven.HelloServlet</servlet-class>
  </servlet>
  <servlet-mapping>
	<servlet-name>helloServlet</servlet-name>
	<url-pattern>/helloServlet</url-pattern>
  </servlet-mapping>

前端编写：jsp

<html>
<body>
<h2>Hello World!</h2>
<a href="helloServlet">Access Servlet</a>
</body>
</html>

• 语法细节不用在意，只是作为演示

war工程-执行Maven构建命令

构建准备-进入pom.xml所在目录

在非pom.xml目录下，是不能执行构建命令的

构建操作-相关命令

命令	操作	解释
mvn clean	删除 target 目录	可以在执行其他命令前执行该命令，确保所有构建数据都是该次构建产生的
mvn compile	主程序编译	主体程序编译结果存放的目录：target/classes
mvn test-compile	测试程序编译	测试程序编译结果存放的目录：target/test-classes
mvn test	进行测试	测试的报告存放的目录：target/surefire-reports
mvn package	打包操作	java工程，打包为：jar 包；JavaWeb工程，打包为：war包。存放的目录：target/
mvn install	安装操作	将本地构建过程中生成的 jar包/war包 存入 Maven 本地仓库，根据Maven坐标找寻对应位置
		该操作也会将pom.xml文件相应打包，名字变了，内容没变

操作注意细节

程序直接执行 mvn compile 命令会报错

DANGER

程序包 javax.servlet.http 不存在

程序包 javax.servlet 不存在

找不到符号

符号: 类 HttpServlet

……

• 上述错误说明：该Web工程需要用到HttpServlet这个类，这个类属于servlet-api.jar包
• 即：该Web工程依赖servlet-api.jar包

配置对servlet-api.jar包的依赖

• 若不知道该jar支持哪个版本，进入该网站浏览：https://mvnrepository.com/

找个人用的多的版本就行

• 找好后，将配置信息写入pom.xml文件

<!-- https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api -->
<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>javax.servlet-api</artifactId>
    <version>3.1.0</version>
    <scope>provided</scope>
</dependency>

war工程-将打包好的war包部署到Tomcat上运行

用部署方式1或2即可

步骤1：将 war 包复制到 Tomcat/webapps 目录下

步骤2：启动 Tomcat

步骤3：浏览器访问

http://localhost:8080/pro02-maven-web/index.jsp

Maven使用-4-命令行操作-让Web工程依赖Java工程

理解：Web工程依赖Java工程

从来只有 Web 工程依赖 Java 工程，没有反过来 Java 工程依赖 Web 工程。本质上来说，Web 工程依赖的 Java 工程其实就是 Web 工程里导入的 jar 包。最终 Java 工程会变成 jar 包，放在 Web 工程的 WEB-INF/lib 目录下

实现：Web工程依赖Java工程

步骤1：pom.xml依赖配置

<!-- 配置对Java工程pro01-maven-java的依赖 -->
<!-- 具体的配置方式：在dependency标签内使用坐标实现依赖 -->
<dependency>
	<groupId>com.atguigu.maven</groupId>
	<artifactId>pro01-maven-java</artifactId>
	<version>1.0-SNAPSHOT</version>
</dependency>

步骤2：创建目录并补充测试代码

• 创建如下目录：pro02-maven-web\src\test\java\com\atguigu\maven
• 将java工程里面的测试代码引入
• 仅引入测试代码，没有引入被测试代码，但是若能正常测试，说明java工程作为jar包被Web工程引用，可以访问没有引入的被测试代码

步骤3：执行测试命令，mvn test

• 执行成功
• 当注释掉步骤1写入的依赖配置，执行失败

步骤4：执行打包命令，mvn package

• war包里面WEB-INF/lib目录下有java工程的jar包

步骤4：查看当前web工程所依赖的jar包列表，mvn dependency:tree

[INFO] com.atguigu.maven:pro02-maven-web:war:1.0-SNAPSHOT
[INFO] +- junit:junit:jar:4.12:test
[INFO] |  \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] +- javax.servlet:javax.servlet-api:jar:3.1.0:provided
[INFO] \- com.atguigu.maven:pro01-maven-java:jar:1.0-SNAPSHOT:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  19.681 s
[INFO] Finished at: 2023-11-10T10:04:29+08:00
[INFO] ------------------------------------------------------------------------

• junit是引入的测试依赖，hamcrest-core是junit根据依赖关系引入的
• servlet-api是引入的servlet依赖
• pro01-maven-java:jar:1.0-SNAPSHOT的存在，说明java工程被构建为jar包，引入web工程

综上，说明Web工程依赖Java工程，即将java工程作为jar包导入到Web工程里面

Maven使用-5-命令行操作-依赖的范围测试

依赖作用范围

依赖标签的位置

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>javax.servlet-api</artifactId>
    <version>3.1.0</version>
    <scope>provided</scope>
</dependency>

依赖标签的可选值

compile、test、provided、system、runtime、import

依赖标签的作用范围

依赖范围	编译环境（main空间）	测试环境（test空间）	运行环境（服务器）	举例	说明
compile	√	√	√	logback	一般是第三方框架的jar包，比如SSM的jar
test	×	√	×	junit	测试过程引入的jar包
provided	√	√	×	servlet-api	开发过程中用到的服务器上存在的jar包，就没必要再次打包发到服务器环境了
runtime	×	√	√	jdbc驱动
system	√	√	×	存储在本地的jar包

• 对于pom.xml文件中配置的依赖，不给出scope标签，默认是compile

依赖作用范围的测试（部分）

验证 compile 范围对 main 目录有效

符合验证内容的预期效果	HelloServlet（main目录） 能够使用 pro01-atguigu-maven 工程（compile范围）中的 Calculator 类
验证方式	在 HelloServlet 类中导入 Calculator 类，然后编译成功

package com.atguigu.maven;
	
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.ServletException;
import java.io.IOException;

// 引入compile依赖的jar包中的类
import com.atguigu.maven.Calculator;

public class HelloServlet extends HttpServlet{
	protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		response.getWriter().write("hello maven web");	
	}	
}

验证 test 范围对 main 目录无效

符合验证内容的预期效果	HelloServlet（main目录） 不能够使用 junit 工程（test范围）中的 Test 类
验证方式	在 HelloServlet 类中导入 Test类，然后编译失败

package com.atguigu.maven;

import org.junit.Test;

public class Calculator {
	
	public int sum(int i, int j){
		return i + j;
	}	
}

验证test和provided范围不参与服务器的部署

符合验证内容的预期效果	通过compile范围依赖的jar包会放入war包，通过test\provided范围依赖的jar包不会放入war包
验证方式	修改依赖的范围，打包，查看war包里面的lib目录即可

验证provided范围对测试程序有效

符合验证内容的预期效果	CalaulatorTest（test目录） 能够使用 servlet-api.jar 工程（provided范围）中的 servlet 类
验证方式	在 CalaulatorTest类中导入 servlet类，然后编译成功

package com.atguigu.maven;

// 导入servlet类
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.ServletException;

import org.junit.Test;
import com.atguigu.maven.Calculator;

// 静态导入的效果是将Assert类中的静态资源导入当前类
// 这样一来，在当前类中就可以直接使用Assert类中的静态资源，不需要写类名
import static org.junit.Assert.*;

public class CalculatorTest{
	
	@Test
	public void testSum(){
		
		// 1.创建Calculator对象
		Calculator calculator = new Calculator();
		
		// 2.调用Calculator对象的方法，获取到程序运行实际的结果
		int actualResult = calculator.sum(5, 3);
		
		// 3.声明一个变量，表示程序运行期待的结果
		int expectedResult = 8;
		
		// 4.使用断言来判断实际结果和期待结果是否一致
		// 如果一致：测试通过，不会抛出异常
		// 如果不一致：抛出异常，测试失败
		assertEquals(expectedResult, actualResult);
		
	}	
}

Maven使用-6-命令行操作-依赖的传递性

A 依赖 B，B 依赖 C，那么在 A 没有配置对 C 的依赖的情况下，A 里面能不能直接使用 C？
B 依赖 C 时使用 compile 范围	可以传递
B 依赖 C 时使用 test 或 provided 范围	不能传递

验证

• 用上述创建的两个工程，一个java工程（作为B）；一个javaWeb工程（作为A）
• 验证compile：在工程B中以compile方式依赖一个jar包
• 验证 test 或 provided：在工程B中以test 、provided方式依赖一个jar包

Maven使用-7-命令行操作-依赖的排除

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

• 调用 mvn dependency:tree 命令查看，已没有相关依赖

Maven使用-8-命令行操作-继承-POM

什么是继承？

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

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

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

应用背景

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

它的项目背景是：

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

它背后的需求是：

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

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

继承示例

在一个工程中依赖多个 Spring 的 jar 包

使用 Spring 时要求所有 Spring 自己的 jar 包版本必须一致。为了能够对这些 jar 包的版本进行统一管理，我们使用继承这个机制，将所有版本信息统一在父工程中进行管理

步骤1：创建步骤跟java工程一样，创建后修改pom.xml文件的打包方式为pom

工程名称：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 工程的工程

步骤2：创建模块

模块工程类似于 IDEA 中的 module，所以需要进入 pro03-maven-parent 工程的根目录，然后运行 mvn archetype:generate 命令来创建模块工程

创建之后，父工程的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> -->

步骤3：在父工程中配置依赖的统一管理

<!-- 使用dependencyManagement标签配置对依赖的管理 -->
<!-- 被管理的依赖并没有真正被引入到工程 -->
<!-- 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>

步骤4：在子工程中配置依赖的统一管理

• 省略版本号

<!-- 子工程引用父工程中的依赖信息时，可以把版本号去掉。	-->
<!-- 把版本号去掉就表示子工程中这个依赖的版本由父工程决定。 -->
<!-- 具体来说是由父工程的dependencyManagement来决定。 -->
<dependencies>
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-core</artifactId>
	</dependency>
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-beans</artifactId>
	</dependency>
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-context</artifactId>
	</dependency>
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-expression</artifactId>
	</dependency>
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-aop</artifactId>
	</dependency>
</dependencies>

• 在父工程中修改版本信息，均会在子工程中进行相应的更改

步骤5：在父工程中声明自定义属性（实现类似公共变量的作用）

• 父工程声明

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

真正实现“一处修改，处处生效”

实际意义

编写一套符合要求、开发各种功能都能正常工作的依赖组合并不容易。如果公司里已经有人总结了成熟的组合方案，那么再开发新项目时，如果不使用原有的积累，而是重新摸索，会浪费大量的时间。为了提高效率，我们可以使用工程继承的机制，让成熟的依赖组合方案能够保留下来。

如上图所示，公司级的父工程中管理的就是成熟的依赖组合方案，各个新项目、子系统各取所需即可

聚合的概念

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

• 项目：整体
• 模块：部分

从继承关系角度来看：

• 父工程
• 子工程

聚合的好处：

• 一键执行 Maven 命令：很多构建命令都可以在“总工程”中一键执行

• 配置聚合之后，各个模块工程会在总工程中展示一个列表，让项目中的各个模块一目了然

聚合的配置

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

聚合可能产生的问题：依赖循环

如果 A 工程依赖 B 工程，B 工程依赖 C 工程，C 工程又反过来依赖 A 工程，那么在执行构建操作时会报下面的错误：

DANGER

[ERROR] [ERROR] The projects in the reactor contain a cyclic reference:

Maven使用-9-结合IDEA构建项目

jar工程

创建步骤

IDEA 2023 专业版

步骤1：调出项目创建框

各项意义

参数	意义
Name	等同于artifactId，Maven工程的工程名
Location	工程的存放位置
JDK	Maven工程的jdk版本（不知道这样解释是否妥当？暂定）
Archetype	选择后缀为quickstart这一项，等同于命令行创建中的如下内容：
	Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): 7:【直接回车，使用默认值】
Version	默认1.1，不知道干啥用
Advanced Settings	配置项目的坐标信息：groupId、artifactId、version

未给出的参数

• pom.xml中的packaging标签：感觉是自行修改，不予给定
  • 补充：在创建Web工程的时候，默认给出并设置为war，不需要再行更改
  • 若需要的是父工程，创建jar工程，手动修改packaging标签的值为pom

<packaging>jar</packaging>

步骤2：创建结果分析

• 默认没有src目录【2023版没有，之前版本是有的】
• 部分maven插件无法下载【第一次创建没问题，后续不知道改了啥，就有问题了】

参数设置

在工程里面进行的参数设置，只适用于该工程

文章后边介绍适用于所有工程的全局Maven配置

步骤3：后续更改–Maven参数设置

• 暂不知道修改的作用，只知道可以修改

• 暂不知道修改的作用，只知道可以修改

步骤4：上述修改完成后，项目的插件就下好了，神奇

步骤5：相关构建操作及jar依赖查看

• 当在pom.xml中增加依赖后，就可以在右侧查看是否刷新添加依赖了

目录结构补充

• 相关模块就创建好了【以约定的目录结构创建】
• IDEA2023之前的版本应该只能创建普通的文件夹对象，然后选中对应文件夹-右键-Mark Directory as-xxx，将文件夹设置为：Sources Root、Test Sources Root等

相对完善的Pom.xml配置

给出相对完善的pom.xml配置，方便在构建项目后，修改相应的配置文件

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

    <!-- 当前Maven工程的打包方式，可选值有下面三种： -->
    <!-- jar：表示这个工程是一个Java工程，在IDEA中没有给出，应该默认是jar工程  -->
    <!-- war：表示这个工程是一个Web工程，需要用到不同于jar工程的创建命令 -->
    <!-- pom：表示这个工程是“管理其他工程”的工程，按照jar工程创建，然后修改打包方式为pom -->
    <packaging>jar</packaging>


    <properties>
        <!-- 改行设置可解决如下警示： -->
        <!-- Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent! -->
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <!-- 指定java编译版本：1.8即java 8 -->
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>
    </properties>

  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <!-- 默认给出的是3.xx的，更改为4.12【因为4.xx版本后才能用@Test注解】 -->
      <version>4.12</version>
      <scope>test</scope>
    </dependency>
      
  </dependencies>

</project>

war工程创建

jar工程创建步骤1的第二张图，其中Archetype修改为如下配置，即可。其余创建步骤不变

Pom工程创建

正常创建jar工程，创建ok后，在pom.xml文件中将packaging设置为pom即可

Maven全局配置信息设置

正常在项目里面进行的Maven配置，只适用于该工程。创建新的工程时，还是会用默认的配置

下边讲述适用于全局Maven配置的操作步骤：

步骤1：若打开了工程，先关闭工程

步骤2：进行配置即可

• 切记不要勾选下边的勾选框，不然每次创建新的工程依旧是默认配置，而不是自定义好的配置信息