Maven

项目构建工具的前世今生

Ant

　　Ant是第一个所谓的“现代构建工具”，用于自动化构建过程。它是用Java实现的，主要用于Java项目。Ant的第一个公开发行版是在2000年，它很快成为Java项目最流行的构建工具，这要归功于它的平台独立性(如Java)，设置门槛低，并提供可重复的构建。后来，它还获得了接受插件的能力。

Maven

　　Maven于2004年首次发布，旨在改进开发人员在使用Ant和其他构建工具时遇到的一些问题。Maven最大的成就被认为是引入了项目结构约定、依赖关系管理和一个中心工件库Maven central。

Gradle

　　Gradle是三个构建工具中最年轻的一个，它的开发人员试图将Ant的能力和灵活性与Maven的依赖关系管理和约定结合起来，以创建漂亮而闪亮的构建工具。经过几年的开发，GradleV1.0于2012年发布，并迅速开始流行起来。它发展得非常快，已经被一些大企业采用——例如，Gradle被选为谷歌Android操作系统的构建工具。

　　一个有趣的观点是，在Gradle中，XML不再被使用。相反，开发人员拥有一种基于JVM语言Groovy的领域特定语言(DSL)，Groovy的发明是为了让开发人员摆脱XML的冗长，编写更简单、更清晰的语句。这在用户中引发了一场争论，即标准的、易于理解的(但冗长的)XML样式比DSL好还是坏。

Maven介绍

什么是Maven

Maven是项目进行模型抽象，充分运用的面向对象的思想，Maven可以通过一小段描述信息来管理项目的构建，报告和文档的软件项目管理工具。Maven 除了以程序构建能力为特色之外，还提供高级项目管理工具。由于 Maven 的缺省构建规则有较高的可重用性，所以常常用两三行 Maven 构建脚本就可以构建简单的项目。

说白了: Maven是由Apache开发的一个工具。用来管理java项目(依赖(jar)管理, 项目构建, 分模块开发 ，管理项目的生命周期).

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

Maven是Apache软件基金会唯一维护的一款自动化构建工具，专注于服务Java平台的项目构建和依赖管理。

Maven是一个强大的Java项目构建工具，基于POM(项目对象模型)文件，可用于项目构建、依赖模块管理和Javadoc生成等。

Maven 是一种声明式项目管理工具，通过在 POM 中配置 “who”,”what”,”where”等信息，即可满足编译、测试、打包、发布等项目构建需求。

Maven的作用

  • 依赖管理: maven对项目的第三方构件（jar包）进行统一管理。向工程中加入jar包不要手工从其它地方拷贝，通过maven定义jar包的坐标，自动从maven仓库中去下载到工程中。

  • 项目构建: maven提供一套对项目生命周期管理的标准，开发人员、和测试人员统一使用maven进行项目构建。项目生命周期管理：编译、测试、打包、部署、运行。

  • maven对工程分模块构建，提高开发效率。 (后面Maven高级会涉及)

为什么用Maven?

（1）jar包的规模

随着我们使用越来越多的框架，或者框架封装程度越来越高，项目中使用的jar包也越来越多。项目中，一个模块里面用到上百个jar包是非常正常的。

比如下面的例子，我们只用到 SpringBoot、SpringCloud 框架中的三个功能：

  • Nacos 服务注册发现
  • Web 框架环境
  • 图模板技术 Thymeleaf

最终却导入了 106 个 jar 包：

此处省略126包的详细信息

而如果使用 Maven 来引入这些 jar 包只需要配置三个『依赖』：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<!-- Nacos 服务注册发现启动器 -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

<!-- web启动器依赖 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<!-- 视图模板技术 thymeleaf -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>

（2）jar包的来源

  • 这个jar包所属技术的官网。官网通常是英文界面，网站的结构又不尽相同，甚至找到下载链接还发现需要通过特殊的工具下载。
  • 第三方网站提供下载。问题是不规范，在使用过程中会出现各种问题。
    • jar包的名称
    • jar包的版本
    • jar包内的具体细节
  • 而使用 Maven 后，依赖对应的 jar 包能够自动下载，方便、快捷又规范。

（3）jar包之间的依赖关系

框架中使用的 jar 包，不仅数量庞大，而且彼此之间存在错综复杂的依赖关系。依赖关系的复杂程度，已经上升到了完全不能靠人力手动解决的程度。另外，jar 包之间有可能产生冲突。进一步增加了我们在 jar 包使用过程中的难度。

下面是前面例子中 jar 包之间的依赖关系：

image-20230917161342014

而实际上 jar 包之间的依赖关系是普遍存在的，如果要由程序员手动梳理无疑会增加极高的学习成本，而这些工作又对实现业务功能毫无帮助。

而使用 Maven 则几乎不需要管理这些关系，极个别的地方调整一下即可，极大的减轻了我们的工作量。

Maven的好处

  • 使用普通方式构建项目

image-20230917161334678

  • 使用Maven构建项目

    image-20230917161330837

Maven仓库和坐标(重点)

Maven的仓库

Maven 仓库是项目中依赖的第三方库

在 Maven 中，任何一个依赖、插件或者项目构建的输出，都可以称之为构件，Maven 仓库能帮助我们管理构件（主要是JAR），它就是放置所有JAR文件（WAR，ZIP，POM等等）的地方

仓库名称 作用
本地仓库 相当于缓存，工程第一次会从远程仓库（互联网）去下载jar 包，将jar包存在本地仓库（在程序员的电脑上）。第二次不需要从远程仓库去下载。先从本地仓库找，如果找不到才会去远程仓库找。
中央仓库 仓库中jar由专业团队（maven团队）统一维护。中央仓库的地址：https://repo1.maven.org/maven2/
远程仓库 在公司内部架设一台私服，其它公司架设一台仓库，对外公开。

注意：除本地仓库以外的仓库都可以叫做远程仓库

当项目编译时，Maven首先从本地仓库中寻找项目所需的Jar包，若本地仓库没有，再到Maven的中央仓库下载所需Jar包，这 3 个仓库中，jar包的查找顺序如下：

image-20220411100417881

本地仓库

Maven 的本地仓库，在安装 Maven 后并不会创建，它是在第一次执行 maven 命令的时候才被创建。默认位置：当前用户名\.m2\repository。

运行 Maven 的时候，Maven 所需要的任何构件都是直接从本地仓库获取的，如果本地仓库没有，它会首先尝试从远程仓库下载构件至本地仓库，然后再使用本地仓库的构件。

本地仓库默认位置在 当前用户名\.m2\repository，我们也可以修改本地仓库的位置，在 maven 安装目录下的 conf/settings.xml文件中可以修改，在该配置文件中可以看到 localRepository 节点被注释掉了，我们可以直接复制该节点，将值修改为本地路径即可

1
2
3
4
5
6
7
<!-- 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>E:/develop/maven_repository</localRepository>

当你运行 Maven 命令，Maven 会将下载依赖的文件放到你指定的路径中。

中央仓库

中央仓库属于远程仓库的一种，Maven 中央仓库是由 Maven 社区提供的仓库，其中包含了绝大多数流行的开源Java构件，以及源码、作者信息、SCM、信息、许可证信息等，一般来说，简单的Java项目依赖的包都可以在这里下载到

中央仓库需要通过网络才能访问，低版本的 maven 中，比如 maven-2.0.10，可以在 ${M2_HOME}/lib/maven-2.0.10-uber.jar 中找到 pom.xml 配置文件

但是在 3.xxx 版本及之后的版本，在 maven 安装目录下的lib/maven-model-builder-${version}.jar下，可以在 \org\apache\maven\model\pom-4.0.0.xml取到 pom-4.0.0.xml 配置文件，该配置文件是所有 Maven POM 的父 POM，所有Maven项目继承该配置

image-20220411101018514

你可以在 pom-4.0.0.xml 配置文件中找到如下配置信息

1
2
3
4
5
6
7
8
9
10
11
12
<repositories>
    <repository>
        <id>central</id>
        <name>Central Repository</name>
        <!-- 默认的中央仓库地址 -->
        <url>https://repo.maven.apache.org/maven2</url>
        <layout>default</layout>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </repository>
</repositories>

可以看到，中央仓库的id为central，远程url地址为 https://repo.maven.apache.org/maven2，它关闭了snapshot版本构件下载的支持

但是国外的远程库下载速度比较慢，甚至可能会出现无法访问的问题，此时我们可以配置国内的仓库，比如阿里云中央仓库等

Maven的坐标

Maven的一个核心的作用就是管理项目的依赖，引入我们所需的各种jar包等。为了能自动化的解析任何一个Java构件，Maven必须将这些Jar包或者其他资源进行唯一标识，这是管理项目的依赖的基础，也就是我们要说的坐标。包括我们自己开发的项目，也是要通过坐标进行唯一标识的，这样才能才其它项目中进行依赖引用。坐标的定义元素如下：

  • groupId:项目组织唯一的标识符，实际对应JAVA的包的结构 (一般写公司的组织名称 eg:com.itheima,com.alibaba)
  • artifactId: 项目的名称
  • version：定义项目的当前版本

例如：要引入druid，只需要在pom.xml配置文件中配置引入druid的坐标即可：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<dependecies>
    <!--druid连接池-->
    <dependency>
        <groupId>com.alibaba</groupId>
        <artifactId>druid</artifactId>    
        <version>1.0.9</version>  
    </dependency>
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>5.1.6</version>
    </dependency>
</dependecies>

小结

  1. 仓库(本地仓库,中央仓库,远程仓库(私服))
    • 先从本地仓库找
      • 如果有, 就直接获得使用
      • 如果没有, 从中央仓库找, 自动的下载到本地仓库
  2. 通过坐标从仓库里面找到对应的jar使用
1
2
3
4
5
<dependency>
  <groupId>com.alibaba</groupId>
  <artifactId>druid</artifactId>    
  <version>1.0.9</version>  
</dependency>
  1. maven坐标搜索网站的地址: https://mvnrepository.com/
  2. 以后工作中maven坐标是直接拷贝

Maven安装

下载Maven

image-20220629114326612

image-20220629114414630

安装Maven

将Maven压缩包解压，即安装完毕

image-20230917163659493

Maven目录介绍

image-20230917163707054

配置环境变量

配置JDK环境

在环境变量中增加MAVEN_HOME

  1. 先在系统变量当中添加一个环境变量 MAVEN_HOME，变量值为 maven 的安装目录的根目录，比如：D:\dev\apache-maven-3.6.3

image-20230917163737091

  1. 然后找到系统变量 Path，给该变量的值后面添加：;%MAVEN_HOME%\bin 即可

image-20230917163743744

  1. 验证

检验 maven 安装是否成功，直接在命令窗口输入 mvn -v ，如果有输出 maven 的版本说明安装成功：

image-20230917163748916

配置本地仓库

将软件文件夹中的repository解压

image-20230917163759949

配置本地仓库

在maven的安装目录中conf/ settings.xml文件，在这里配置本地仓库

image-20230917163806073

  • 示例代码
1
2
3
4
5
6
7
8
9
10
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
  <!-- 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>E:/source/04_Maven/repository_pinyougou</localRepository>

测试Maven安装成功

打开cmd本地控制台，输入mvn -version

image-20230917165008699

小结

  1. 注意事项
    • Maven安装包 和仓库 都需要解压到一个没有中文和空格的目录下(建议解压到不同的目录)
    • 配置
      • MAVEN_HOME 配置到Maven的解压目录
      • Path 配置到bin目录
    • 在apache-maven-3.3.9\conf\settings.xml配置本地仓库

项目中配置镜像仓库

我们是可以在自己的项目中配置镜像仓库的

配置我们自己的远程仓库有很多好处，比如你有一个局域网的远程仓库，使用该仓库能大大提高下载速度，继而提高构建速度，也有可能你依赖的一个 jar 在 central 中找不到，它只存在于某个特定的公共仓库，这样你也不得不添加那个远程仓库的配置。

我们可以在项目的 pom.xml 文件中配置远程仓库。比如下面配置远程仓库指向阿里云仓库

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<?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>org.heima</groupId>
    <artifactId>maven_project</artifactId>
    <version>1.0-SNAPSHOT</version>
    <repositories>
        <repository>
            <id>maven-ali</id>
            <url>http://maven.aliyun.com/nexus/content/repositories/central</url>
            <releases>
                <enabled>true</enabled>
            </releases>
            <snapshots>
                <enabled>true</enabled>
                <updatePolicy>always</updatePolicy>
                <checksumPolicy>fail</checksumPolicy>
            </snapshots>
        </repository>
    </repositories>
</project>

<repositories>下面可以添加多个<repository>，每个<repository>都有它唯一的ID，一个描述性的name，以及最重要的远程仓库的url。

<releases><enabled>true</enabled></releases>告诉Maven可以从这个仓库下载 releases 版本的构件，而<snapshots><enabled>false</enabled></snapshots> 告诉Maven不要从这个仓库下载 snapshot 版本的构件，禁止从公共仓库下载snapshot构件是推荐的做法，因为这些构件不稳定，且不受你控制，你应该避免使用，当然，如果你想使用局域网内组织内部的仓库，你可以激活snapshot的支持。

settings.xml配置镜像仓库

在项目的 pom.xml 文件中可以配置中央仓库，但是这样每个项目都需要配置一遍，需要重复工作

我们可以直接在 maven 安装目录下的 conf/settings.xml 文件中配置中央仓库。

找到 mirrors 标签，添加如下配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<mirrors>
    <!-- mirror
     | Specifies a repository mirror site to use instead of a given repository. The repository that
     | this mirror serves has an ID that matches the mirrorOf element of this mirror. IDs are used
     | for inheritance and direct lookup purposes, and must be unique across the set of mirrors.
     |
    <mirror>
      <id>mirrorId</id>
      <mirrorOf>repositoryId</mirrorOf>
      <name>Human Readable Name for this Mirror.</name>
      <url>http://my.repository.com/repo/path</url>
    </mirror>
     -->
    <mirror>
        <id>alimaven</id>
        <name>aliyun maven</name>
        <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
        <mirrorOf>central</mirrorOf>
    </mirror>
</mirrors>

可以看到 <mirrorOf> 的值是 central，意思就是用以上镜像替代 Maven 自带的中央仓库

IDEA集成Maven(很重要)

maven在idea中配置

  • 配置Maven

image-20230917165131230

配置默认Maven环境 目的: 为了下次创建的时候 不需要再选择Maven了, 使用的就是这个默认环境的

  • 配置参数(解决创建慢的问题) -DarchetypeCatalog=internal

image-20230917165137881

  • 然后新创建project，一定不要使用原来的project，要求各位第一次使用maven创建项目的时候，一定要联网

maven工程目录结构

Maven 提倡使用一个共同的标准目录结构，Maven 使用约定优于配置的原则，大家尽可能的遵守这样的目录结构，一个使用Maven管理的普通的Java项目，它的目录结构默认如下：

1
2
3
4
5
6
7
8
9
10
11
12
MavenProject
       |-- pom.xml   maven项目的配置文件。对项目中的所有jar包依赖进行统一管理
       |-- src
           |-- main
                | -- java  存放项目源代码
                | -- resources（可省略）  存放项目配置文件 .xml等 
           |-- test（可省略）
                | -- java  存放单元测试源代码
                | -- resources   存放单元测试资源文件 .xml等
       |-- target（由maven生成）  存放所有编译、打包生成的文件
           |-- classes  存放项目源代码编译输出的字节码文件
           |-- test-classes  存放测试代码编译输出的字节码文件

默认情况下，项目在编译过后，会将 src/main/java编译过后的字节码文件和 src/main/resource 中的文件放在target/classes目录下。

但是，src/main/java 目录下的非包且非java的文件在编译过后并不会自动被拷贝在 target/classes 目录下，而是会丢失。

如果我们想要将 src/main/java 目录下的非包且非java的文件也一并拷贝在target/classes 目录下，则需要在 pom.xml 文件的 build 标签下进行配置。

IDEA创建Maven工程

创建javase工程

创建java工程

image-20230917165150888

image-20230917165155380

image-20230917165205360

image-20230917165209507

java工程目录结构

  • 需要main/java文件夹变成 源码的目录(存放java源码)

image-20230917165224205

  • 需要test/java文件夹变成 测试源码的目录(存放单元测试)

image-20230917165230097

  • 创建resources目录, 变成资源的目录

    image-20230917165234264

  • 整体结构

    image-20230917165239875

编写Hello World！

image-20230917165246673

image-20230917165251072

小结

  1. JavaSe工程的骨架

image-20230917165258729

  1. 项目的结构

image-20230917165302519

创建javaweb工程

创建javaweb工程

  • 创建javaweb工程与创建javase工程类似，但在选择Maven骨架时，选择maven-archetype-webapp即可：

image-20230917165328243

  • 创建好的javaweb工程如下：

image-20230917165343821

  • 所以，要手动创建一个java目录用于编写java代码：

image-20230917165348494

  • 还要将java目录添加为Source Root：

image-20230917165354547

发布javaweb工程

image-20230917165400107

浏览器访问效果

image-20230917165404996

target目录

image-20220708033039215

小结

  1. 选择骨架选择webapp

image-20191224105135578

  1. pom.xml

image-20191224105159688

  1. web工程结构

image-20191224105359670

image-20220708032800465

不使用骨架创建工程

不使用骨架创建javase项目

  • 第一步

image-20230917165428212

  • 第二步

image-20230917165433082

  • 第三步

image-20230917165437380

  • 第四步

image-20230917165442221

不使用骨架创建javaweb项目

  • 安装一个插件(JBLJavaToWeb)
  • 第一步

image-20230917165447201

  • 第二步

image-20230917170944047

  • 第三步

image-20230917170951224

  • 第四步

image-20230917170955706

小结

我们可以使用JBLJavaToWeb插件，轻松地将没有使用骨架创建的java项目转换成javaweb项目

image-20220708032917810

Maven常用命令

Maven的常用命令管理项目的生命周期

clean命令

清除编译产生的target文件夹内容，可以配合相应命令一起使用，如mvn clean package， mvn clean test

image-20230917171013024

image-20230917171006970

compile命令

该命令可以对src/main/java目录的下的代码进行编译

image-20230917171019732

image-20230917171024179

test命令

测试命令,先将src/main/java以及src/test/java中的类都进行编译，然后再执行src/test/java/下所有junit的测试用例

image-20230917171031126

  • 在src/test/java下创建测试类DemoTest

image-20230917171034939

  • 执行test命令测试

image-20230917171215741

  • 控制台显示测试结果

image-20230917171220781

package命令

mvn package，打包项目

先编译，再执行测试，然后再打包(只会将main/java里面的代码打到包)

  • 如果是JavaSe的项目,打包成jar包
  • 如果是JavaWeb的项目,打包成war包

image-20230917171232490

image-20230917171235994

打包后的项目会在target目录下找到

image-20230917171240035

install命令

mvn install，打包后将其安装在本地仓库

image-20230917171246698

image-20230917171249920

安装完毕后，在本地仓库中可以找到itheima_javase_demo的信息

image-20230917171253868

小结

  1. 命令作用

    • clean 用来清除编译后的文件(target文件夹里面的)【一般清缓存】
    • compile 编译只会编译main里面的内容
    • test 执行单元测试，先将main、test中的内容进行编译，然后执行test中的测试方法
    • package 打包 (javaSe–>jar, javaweb–>war)，其实执行打包之前先执行test，然后对项目进行打包
    • install 把项目打包之后安装到本地仓库，其实执行install之前先执行了打包，然后对项目进行安装到本地仓库

  2. 生命周期

    当我们执行了install 也会执行compile test package

Maven依赖管理(引入依赖)

导入依赖

导入依赖坐标，无需手动导入jar包就可以引入jar。在pom.xml中使用<dependency>标签引入依赖。

做项目/工作里面 都有整套的依赖的, 不需要背诵的.

去Maven官网找, 赋值,粘贴. http://mvnrepository.com/

导入junit的依赖

  • 导入junit坐标依赖
1
2
3
4
5
6
<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.12</version>
    <scope>test</scope>
</dependency>
  • 进行单元测试
1
2
3
4
5
6
7
8
import org.junit.Test;

public class DemoTest {
    @Test
    public void test1(){
        System.out.println("test running...");
    }
}

导入servlet的依赖

  • 创建Servlet，但是发现报错，原因是没有导入Servlet的坐标依赖

image-20230917171301741

  • 导入Servlet的坐标依赖
1
2
3
4
5
6
<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>javax.servlet-api</artifactId>
    <version>3.1.0</version>
    <scope>provided</scope>
</dependency>
  • 原有报错的Servlet恢复正常

image-20230917171306798

依赖范围

image-20230917171310809

  • compile 编译、测试、运行，A在编译时依赖B，并且在测试和运行时也依赖

    例如：strus-core、spring-beans, C3P0,Druid。打到war包或jar包

  • provided 编译、和测试有效，A在编译和测试时需要B

    例如：servlet-api就是编译和测试有用，在运行时不用（tomcat容器已提供）

    不会打到war

  • runtime：测试运行有效,

    例如：jdbc驱动包 ，在开发代码中针对java的jdbc接口开发，编译不用

    在运行和测试时需要通过jdbc驱动包（mysql驱动）连接数据库，需要的

    会打到war

  • test：只是测试有效，只在单元测试类中用

    例如：junit

    不会打到war

  • 按照依赖强度，由强到弱来排序：(理解)

    compile> provided> runtime> test

小结

  1. 坐标不需要背, 做项目时候/工作开发 都有整套的坐标. 如果是导入一些特定, 可以查阅网站,直接拷贝

  2. 作用范围

    • compile 编译、测试、打包运行部署 有效 【默认】
    • provided 编译, 测试 有效. 打包运行部署 无效
    • runtime 测试、打包运行部署 有效 编译无效
    • test 只是测试有效，只在单元测试类中用

  3. Servlet,JSP 这类jar 需要加上provided , 因为部署到Tomcat里面. tomcat里面有, 如果没有加上provided , 可能会导致jar 冲突

    单元测试的 建议加上test

Maven插件(了解)

Maven是一个核心引擎，提供了基本的项目处理能力和建设过程的管理，以及一系列的插件是用来执行实际建设任务。maven插件可以完成一些特定的功能。例如，集成jdk插件可以方便的修改项目的编译环境；集成tomcat插件后，无需安装tomcat服务器就可以运行tomcat进行项目的发布与测试。在pom.xml中通过plugin标签引入maven的功能插件。

JDK编译版本的插件【了解】

1
2
3
4
5
6
7
8
9
10
11
<!--jdk编译插件-->
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.2</version>
    <configuration>
        <source>1.8</source>
        <target>1.8</target>
        <encoding>utf-8</encoding>
    </configuration>
</plugin>

Tomcat7服务端的插件(部署项目)

  • 添加tomcat7插件
1
2
3
4
5
6
7
8
9
10
11
12
<plugins>
    <plugin>
        <groupId>org.apache.tomcat.maven</groupId>
        <artifactId>tomcat7-maven-plugin</artifactId>
        <configuration>
            <!-- 指定端口 -->
            <port>82</port>
            <!-- 请求路径 -->
            <path>/</path>
        </configuration>
    </plugin>
</plugins>

注意: Maven的中央仓库中只有Tomcat7.X版本的插件，而之前我们使用的是8.X的版本，如果想使Tomcat8.X的插件可以去其他第三方仓库进行寻找，或者使用IDEA集成外部Tomcat8极其以上版本，进行项目的发布。

小结

1
2
3
4
5
6
<build>
    <plugins>
           <plugin></plugin> 
           <plugin></plugin> 
    </plugins>
</build>

maven配置修改

修改不使用骨架创建maven项目的默认编译版本

  1. 不使用骨架创建的maven项目的默认编译版本是1.5或者1.4版本

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    <profile>   
            <id>jdk1.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>
                <encoding>UTF-8</encoding>
            </properties>   
    </profile>
    将上述标签内容添加到settings文件的<profiles>标签中

彻底解决引入依赖的时候卡、报错

修改settings.xml文件，添加如下代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
<mirrors>
      <mirror>
          <id>alimaven</id>
          <name>aliyun maven</name>
          <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
          <mirrorOf>central</mirrorOf>
      </mirror>
      <mirror>
          <id>uk</id>
          <mirrorOf>central</mirrorOf>
          <name>Human Readable Name for this Mirror.</name>
          <url>http://uk.maven.org/maven2/</url>
      </mirror>

      <mirror>
          <id>CN</id>
          <name>OSChina Central</name>
          <url>http://maven.oschina.net/content/groups/public/</url>
          <mirrorOf>central</mirrorOf>
      </mirror>

      <mirror>
          <id>nexus</id>
          <name>internal nexus repository</name>
          <url>http://repo.maven.apache.org/maven2</url>
          <mirrorOf>central</mirrorOf>
      </mirror>
  </mirrors>

注意点

  1. 引入依赖之后，要检查依赖是否引入成功

image-20230917171716634

  1. 如果dependencies中大块报红

    1. 先使用cleanLastUpdated文件，进行清理。清完之后刷新
    2. 检查自己的maven配置是否正确

    image-20230917171721680

    1. 检查settings.xml中的本地仓库路径配置是否正确

    image-20230917171731555

    1. 将所有的依赖删除，接着一个一个依赖添加，添加一个就刷新一下，看是否添加成功，如果发现了哪个依赖报错，很有可能是因为你的本地仓库中没有该版本，所以我们可以尝试切换版本

maven私服【了解】

私服概述

公司在自己的局域网内搭建自己的远程仓库服务器，称为私服， 私服服务器即是公司内部的 maven 远程仓库， 每个员工的电脑上安装 maven 软件并且连接私服服务器，员工将自己开发的项目打成 jar 并发布到私服服务器，其它项目组从私服服务器下载所依赖的构件（jar）。私服还充当一个代理服务器，当私服上没有 jar 包会从互联网中央仓库自动下载，如下
图 :

image-20230917171736830

私服也属于远程仓库的一种，一般来说，私服仓库搭建在公司局域网内，专供公司内部开发人员提供服务，不是对外使用的

一般Maven下载jar包的步骤是：本地仓库（本机）--->私服（局域网）--->中心仓库（外部网络）

私服搭建

下载 nexus

Nexus 是 Maven 仓库管理器， 通过 nexus 可以搭建 maven 仓库，同时 nexus 还提供强大的仓库管理功能，构件搜索功能等。
下载地址： http://www.sonatype.org/nexus/archived/

下载： nexus-2.12.0-01-bundle.zip

image-20230917171838275

安装 nexus

解压 nexus-2.12.0-01-bundle.zip，进入 bin 目录：

image-20230917171842690

以管理员权限运行命令行,进入 bin 目录，执行 nexus.bat install

image-20230917171846939

安装成功在服务中查看有 nexus 服务：

image-20230917171850718

卸载nexus

cmd 进入 nexus 的 bin 目录，执行： nexus.bat uninstall

image-20230917171854949

启动 nexus

  • 方式一

    cmd 进入 bin 目录，执行 nexus.bat start

  • 方式二

    直接启动 nexus 服务

    image-20230917171900392

登录

  • 访问: http://localhost:8081/nexus/

    查看 nexus 的配置文件 conf/nexus.properties ,里面有端口号

image-20230917171906111

  • 点击右上角的 Log in，输入账号和密码 登陆 (账号admin,密码admin123 )

image-20230917171911308

  • 登录成功

image-20230917171915945

仓库类型

image-20230917171919860

image-20230917171924615

image-20230917171929705

nexus 的仓库有 4 种类型：

image-20230917171933551

  1. hosted，宿主仓库， 部署自己的 jar 到这个类型的仓库，包括 releases 和 snapshot 两部分， Releases 公司内部发布版本仓库、 Snapshots 公司内部测试版本仓库
  2. proxy，代理仓库， 用于代理远程的公共仓库，如 maven 中央仓库，用户连接私服，私服自动去中央仓库下载 jar 包或者插件。
  3. group，仓库组，用来合并多个 hosted/proxy 仓库，通常我们配置自己的 maven 连接仓库组。
  4. virtual(虚拟)：兼容 Maven1 版本的 jar 或者插件

小结

  1. 对着文档搭建一下就OK

  2. 安装的时候需要以管理员 身份

  3. 路径不要有中文

私服使用

将项目发布到私服

需求

企业中多个团队协作开发通常会将一些公用的组件、开发模块等发布到私服供其它团队或模块开发人员使用。
本例子假设多团队分别开发 . 某个团队开发完在common_utils, 将 common_utils发布到私服供 其它团队使用.

配置

第一步： 需要在客户端即部署common_utils工程的电脑上配置 maven环境，并修改 settings.xml文件(Maven配置文件)， 配置连接私服的用户和密码 。此用户名和密码用于私服校验，因为私服需要知道上传的账号和密码是否和私服中的账号和密码一致 (配置到<servers>标签下)

1
2
3
4
5
6
7
8
9
10
<server>
    <id>releases</id>
    <username>admin</username>
    <password>admin123</password>
</server>
<server>
    <id>snapshots</id>
    <username>admin</username>
    <password>admin123</password>
</server>

releases: 连接发布版本项目仓库
snapshots: 连接测试版本项目仓库

image-20230917171940089

第二步： 在需要发布配置项目 pom.xml . 配置私服仓库的地址，本公司的自己的 jar 包会上传到私服的宿主仓库，根据工程的版本号决定上传到哪个宿主仓库，如果版本为 release 则上传到私服的 release 仓库，如果版本为snapshot 则上传到私服的 snapshot 仓库 .

1
2
3
4
5
6
7
8
9
10
<distributionManagement>
    <repository>
        <id>releases</id>
        <url>http://localhost:8081/nexus/content/repositories/releases/</url>
    </repository>
    <snapshotRepository>
        <id>snapshots</id>
        <url>http://localhost:8081/nexus/content/repositories/snapshots/</url>
    </snapshotRepository>
</distributionManagement>
  • 注意： pom.xml 这里<id> 和 settings.xml 配置<id>对应！
测试

1、 首先启动 nexus
2、 对 common_utils工程执行 deploy 命令

根据本项目pom.xml中version定义决定发布到哪个仓库，如果version定义为snapshot，执行 deploy后查看 nexus 的 snapshot仓库， 如果 version定义为 release则项目将发布到 nexus的 release 仓库，本项目将发布到 snapshot 仓库：

image-20191222211914094

从私服下载 jar 包

需求

没有配置 nexus 之前，如果本地仓库没有，去中央仓库下载，通常在企业中会在局域网内部署一台私服服务器， 有了私服本地项目首先去本地仓库找 jar，如果没有找到则连接私服从私服下载 jar 包，如果私服没有 jar 包私服同时作为代理服务器从中央仓库下载 jar 包，这样做的好处是一方面由私服对公司项目的依赖 jar 包统一管理，一方面提高下载速度， 项目连接私服下载 jar 包的速度要比项目连接中央仓库的速度快的多。

本例子测试从私服下载 commons-utils工程 jar 包。

在 settings.xml 中配置仓库

在客户端的 settings.xml 中配置私服的仓库，由于 setting.xml 中没有 repositories 的配置标签需要使用 profile 定义仓库。(配置在<profiles>标签下)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
<profile>
    <!--profile 的 id-->
    <id>dev</id>
    <repositories>
        <repository>
        <!--仓库 id， repositories 可以配置多个仓库，保证 id 不重复-->
        <id>nexus</id>
        <!--仓库地址，即 nexus 仓库组的地址-->
        <url>http://localhost:8081/nexus/content/groups/public/</url>
        <!--是否下载 releases 构件-->
        <releases>
            <enabled>true</enabled>
        </releases>
        <!--是否下载 snapshots 构件-->
        <snapshots>
            <enabled>true</enabled>
        </snapshots>
    </repository>
    </repositories>
    <pluginRepositories>
        <!-- 插件仓库， maven 的运行依赖插件，也需要从私服下载插件 -->
        <pluginRepository>
            <!-- 插件仓库的 id 不允许重复，如果重复后边配置会覆盖前边 -->
            <id>public</id>
            <name>Public Repositories</name>
            <url>http://localhost:8081/nexus/content/groups/public/</url>
        </pluginRepository>
    </pluginRepositories>
</profile>

使用 profile 定义仓库需要激活才可生效。 

1
2
3
<activeProfiles>
    <activeProfile>dev</activeProfile>
</activeProfiles>
测试从私服下载 jar 包

  • 删掉本地仓库的day01_javase_02

  • 编译依赖day01_javase_02的工程

image-20191222212314528

  • 出现如下日志

image-20191222212255624

小结

  1. 对着文档操作

maven安装Jar

把jar安装到本地仓库(掌握)

  • 随便找一个 jar 包测试， 可以先 CMD进入到 jar 包所在位置，运行
1
mvn install:install-file -DgroupId=com.itheima -DartifactId=nbutil -Dversion=1.1.37 -Dfile=nbutil-1.1.37.jar -Dpackaging=jar

image-20230917172054882

image-20230917172059430

把jar安装到私服

需要在 maven 软件的核心配置文件 settings.xml 中配置第三方仓库的 server 信息 

1
2
3
4
5
<server>
    <id>thirdparty</id>
    <username>admin</username>
    <password>admin123</password>
</server>

才能执行一下命令 

1
mvn deploy:deploy-file -DgroupId=com.itheima -DartifactId=nbutil -Dversion=1.1.37 -Dpackaging=jar -Dfile=nbutil-1.1.37.jar -Durl=http://localhost:8081/nexus/content/repositories/thirdparty/ -DrepositoryId=thirdparty

image-20230917172111669

image-20230917172116531

参数说明

DgroupId 和 DartifactId 构成了该 jar 包在 pom.xml 的坐标，项目就是依靠这两个属性定位。自己起名字也行。

Dfile 表示需要上传的 jar 包的绝对路径。

Durl 私服上仓库的位置，打开 nexus——>repositories 菜单，可以看到该路径。

DrepositoryId 服务器的表示 id，在 nexus 的 configuration 可以看到。

Dversion 表示版本信息。

关于 jar 包准确的版本：

包的名字上一般会带版本号，如果没有那可以解压该包，会发现一个叫 MANIFEST.MF 的文件

这个文件就有描述该包的版本信息。

比如 Specification-Version: 2.2 可以知道该包的版本了。

上传成功后，在 nexus 界面点击 3rd party 仓库可以看到这包。

小结

  1. 有些jar中央仓库没有(eg:oracle驱动), 从官网/网络上下载下来, 安装到本地仓库. 我们的Maven项目就可以使用了
  2. 具体操作参考文档

cleanLastUpdated.bat

清理无效jar包脚本

1
2
3
4
5
6
7
set REPOSITORY_PATH=C:\maven\apache-maven-3.5.2\repository
rem 正在搜索...
for /f "delims=" %%i in ('dir /b /s "%REPOSITORY_PATH%\*lastUpdated*"') do (
    del /s /q %%i
)
rem 搜索完毕
pause

Pom层次

Pom文件简介

而 pom.xml 主要描述了项目的基本信息，用于描述项目如何构建，声明项目依赖等等，是项目级别的配置文件，执行任务或目标时，Maven 会在当前目录中查找 POM，然后读取 POM，获取所需的配置信息，然后执行目标。

pom（project object model）即项目对象模型，maven 把一个项目的结构和内容抽象成一个模型，在 xml 文件中进行声明，以方便进行构建和描述。

Super POM

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

关于超级 POM，Maven 官网是这样介绍的：

The Super POM is Maven’s default POM. All POMs extend the Super POM unless explicitly set, meaning the configuration specified in the Super POM is inherited by the POMs you created for your projects.

译文：Super POM 是 Maven 的默认 POM。除非明确设置，否则所有 POM 都扩展 Super POM，这意味着 Super POM 中指定的配置由您为项目创建的 POM 继承。

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

这个POM文件可以在 [Maven Super Pom](Maven Model Builder – Super POM) 找到。

也可以在 本地这个路径找到 $MAVEN_HOME/lib/maven-model-builder-3.8.1.jar!/org/apache/maven/model/pom-4.0.0.xml

1. repositories

定义了一个名叫 central的repository，value是 ‘https://repo.maven.apache.org/maven2'，可以从这个地址拉下来dependency。

2. pluginRepositories

默认 plugin的 repositories

3. build

设置了一些默认的路径，其中还定义了 几个插件，不过Maven官方也提醒，未来的版本会去掉。

1
2
3
4
<pluginManagement>
    <!-- NOTE: These plugins will be removed from future versions of the super POM -->
    <!-- They are kept for the moment as they are very unlikely to conflict with lifecycle mappings (MNG-4453) -->
</pluginManagement>

父 POM

和 Java 类一样，POM 之间其实也是单继承的。如果我们给一个 POM 指定了父 POM，那么继承关系如下图所示：

image-20220701112032458

有效 POM

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

查看有效 POM：

mvn help:effective-pom

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

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

Pom文件构成

一个基本的pom.xml文件配置如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?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">
    <!-- maven模型的版本，对于maven2和maven3来说，只能是4.0.0 -->
    <modelVersion>4.0.0</modelVersion>

    <!-- 公司或者组织的唯一标志，一般是公司域名的倒写，或者是公司域名倒写+项目名。并且配置时生成的路径也是由此生成， 如com.companyname.project-group，maven会将该项目打成的jar包放本地路径：/com/companyname/project-group -->
    <groupId>org.heima</groupId>
    
    <!-- 项目的唯一ID，一个groupId下面可以有多个项目，通过artifactId来区分 -->
    <artifactId>maven_project</artifactId>

    <!-- 项目的版本号 -->
    <version>1.0-SNAPSHOT</version>
</project>

所有 POM 文件都需要 <project> 标签元素和该标签下的三个必需字段：groupId，artifactId，version。

groupId + artifactId + version = 坐标，坐标可用于标识互联网中的唯一资源，在Maven中，坐标是Jar包的唯一标识，Maven通过坐标在仓库中找到项目所需的Jar包。

常见标签

下面我们看下Maven中的常用标签

parent标签

在maven多模块项目中引用父pom依赖，在springboot项目中就有父依赖

1
2
3
4
5
6
<!--引用springBoot父项目-->
<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.2.2.RELEASE</version>
</parent>

properties标签

定义一些全局属性值，常用于jar包版本定义全局管理jar包版本后面可以${} 取值

在springboot项目中父pom会定义一些项目jar包版本依赖 ，所以我们在引用jar时候才不用写jar包版本，会自动跟随父pom中定义的jar包版本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-dependencies</artifactId>
    <version>2.4.7</version>
</parent>

<properties>
    <activemq.version>5.15.11</activemq.version>
    <antlr2.version>2.7.7</antlr2.version>
    <appengine-sdk.version>1.9.77</appengine-sdk.version>
    <artemis.version>2.10.1</artemis.version>
    <aspectj.version>1.9.5</aspectj.version>
    <assertj.version>3.13.2</assertj.version>
    <atomikos.version>4.0.6</atomikos.version>
    <awaitility.version>4.0.1</awaitility.version>
    <bitronix.version>2.1.4</bitronix.version>
    <build-helper-maven-plugin.version>3.0.0</build-helper-maven-plugin.version>
    <byte-buddy.version>1.10.4</byte-buddy.version>
    <caffeine.version>2.8.0</caffeine.version>
    <cassandra-driver.version>3.7.2</cassandra-driver.version>
    <classmate.version>1.5.1</classmate.version>
    <commons-codec.version>1.13</commons-codec.version>
  </properties>

dependencyManagement标签

在Maven多模块的时候，管理依赖关系是非常重要的，各种依赖包冲突，查询问题起来非常复杂，于是就用到了，在springboot项目中父模块就定义了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot</artifactId>
        <version>2.2.2.RELEASE</version>
      </dependency>
      <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-test</artifactId>
        <version>2.2.2.RELEASE</version>
      </dependency>
      <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-test-autoconfigure</artifactId>
        <version>2.2.2.RELEASE</version>
      </dependency>
  </dependencyManagement>

那么在子模块中只需要<groupId>和<artifactId>即可，不需要加入版本号，

1
2
3
4
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

使用dependencyManagement可以统一管理项目的版本号，确保应用的各个项目的依赖和版本一致，不用每个模块项目都弄一个版本号，不利于管理，当需要变更版本号的时候只需要在父类容器里更新，不需要任何一个子项目的修改；如果某个子项目需要另外一个特殊的版本号时，只需要在自己的模块dependencies中声明一个版本号即可。子类就会使用子类声明的版本号，不继承于父类版本号

dependencies标签

用于引入项目依赖

1
2
3
4
5
6
7
<dependencies>
    <!--aop 切面-->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-aop</artifactId>
    </dependency>
</dependencies>
dependencies和dependencyManagement区别

Dependencies相对于dependencyManagement，所有声明在dependencies里的依赖都会自动引入，并默认被所有的子项目继承， 而dependencyManagement里只是声明依赖，并不自动实现引入，因此子项目需要显示的声明需要用的依赖。

如果不在子项目中声明依赖，是不会从父项目中继承下来的；只有在子项目中写了该依赖项，并且没有指定具体版本，才会从父项目中继承该项，并且version和scope都读取自父pom;另外如果子项目中指定了版本号，那么会使用子项目中指定的jar版本。

build标签

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

所以本质上来说：我们配置的 build 标签都是对超级 POM 配置的叠加。那我们又为什么要在默认配置的基础上叠加呢？很简单，在默认配置无法满足需求的时候定制构建过程。

build 标签组成

从示例中我们能够看到，build 标签的子标签大致包含三个主体部分：

① 定义约定的目录结构

参考示例中的如下部分：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<directory>${project.basedir}/target</directory>
<outputDirectory>${project.build.directory}/classes</outputDirectory>
<finalName>${project.artifactId}-${project.version}</finalName>
<testOutputDirectory>${project.build.directory}/test-classes</testOutputDirectory>
<sourceDirectory>${project.basedir}/src/main/java</sourceDirectory>
<scriptSourceDirectory>${project.basedir}/src/main/scripts</scriptSourceDirectory>
<testSourceDirectory>${project.basedir}/src/test/java</testSourceDirectory>
<resources>
  <resource>
    <directory>${project.basedir}/src/main/resources</directory>
  </resource>
</resources>
<testResources>
  <testResource>
    <directory>${project.basedir}/src/test/resources</directory>
  </testResource>

我们能看到各个目录的作用如下：

目录名 作用
sourceDirectory 主体源程序存放目录
scriptSourceDirectory 脚本源程序存放目录
testSourceDirectory 测试源程序存放目录
outputDirectory 主体源程序编译结果输出目录
testOutputDirectory 测试源程序编译结果输出目录
resources 主体资源文件存放目录
testResources 测试资源文件存放目录
directory 构建结果输出目录

② 备用插件管理

pluginManagement 标签存放着几个插件：

  • maven-antrun-plugin
  • maven-assembly-plugin
  • maven-dependency-plugin
  • maven-release-plugin

通过 pluginManagement 标签管理起来的插件就像 dependencyManagement 一样，子工程使用时可以省略版本号，起到在父工程中统一管理版本的效果。情看下面例子：

  • 被 spring-boot-dependencies 管理的插件信息：
  • 子工程使用的插件信息：
1
2
3
4
5
6
7
8
<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

③生命周期插件

plugins 标签存放的是默认生命周期中实际会用到的插件，这些插件想必大家都不陌生，所以抛开插件本身不谈，我们来看看 plugin 标签的结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<plugin>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.1</version>
    <executions>
        <execution>
            <id>default-compile</id>
            <phase>compile</phase>
            <goals>
                <goal>compile</goal>
            </goals>
        </execution>
        <execution>
            <id>default-testCompile</id>
            <phase>test-compile</phase>
            <goals>
                <goal>testCompile</goal>
            </goals>
        </execution>
    </executions>
</plugin>

典型应用：指定 JDK 版本

① 提出问题

前面我们在 settings.xml 中配置了 JDK 版本，那么将来把 Maven 工程部署都服务器上，脱离了 settings.xml 配置，如何保证程序正常运行呢？思路就是我们直接把 JDK 版本信息告诉负责编译操作的 maven-compiler-plugin 插件，让它在构建过程中，按照我们指定的信息工作。

② 暂时取消 settings.xml 配置

为了测试对 maven-compiler-plugin 插件进行配置的效果，我们暂时取消 settings.xml 中的 profile 配置。

1
2
3
4
5
6
7
8
9
10
11
12
13
<!-- 配置Maven工程的默认JDK版本 -->
<!-- <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> -->

③ 编写源文件代码

很明显这里用到了 Lambda 表达式，这是 JDK 1.8 才支持的语法。

1
2
3
4
5
6
7
8
9
10
11
package com.itheima.maven;

public class Hello {

    public void hello() {
        new Thread(()->{
            System.out.println("thread ...");
        }).start();
    }

}

此时我们执行编译命令：

image-20220701160437052

④ 配置构建过程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<!-- build 标签：意思是告诉 Maven，你的构建行为，我要开始定制了！ -->
<build>
    <!-- plugins 标签：Maven 你给我听好了，你给我构建的时候要用到这些插件！ -->
    <plugins>
        <!-- plugin 标签：这是我要指定的一个具体的插件 -->
        <plugin>
            <!-- 插件的坐标。此处引用的 maven-compiler-plugin 插件不是第三方的，是一个 Maven 自带的插件。 -->
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.1</version>
            
            <!-- configuration 标签：配置 maven-compiler-plugin 插件 -->
            <configuration>
                <!-- 具体配置信息会因为插件不同、需求不同而有所差异 -->
                <source>1.8</source>
                <target>1.8</target>
                <encoding>UTF-8</encoding>
            </configuration>
        </plugin>
    </plugins>
</build>

⑤ 再次执行编译命令

image-20220701160517183

⑥ 两种配置方式比较

  • settings.xml 中配置：仅在本地生效，如果脱离当前 settings.xml 能够覆盖的范围，则无法生效。
  • 在当前 Maven 工程 pom.xml 中配置：无论在哪个环境执行编译等构建操作都有效。

还有另外一种方式

1
2
3
4
5
<properties>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

依赖管理

依赖传递

image-20230917172544222

传递性依赖机制

项目A中，我们为了实现某一个功能通常会引入第三方库，这里是一个compile依赖范围的B依赖，而B依赖同时又依赖于另一个compile依赖范围的C组件。

那么对A而言，C就是它的一个传递性依赖，在Maven中，其会将我们在POM文件中显式声明的直接依赖(本例的B依赖)引入到项目中，对于必要的间接依赖(本例的C依赖)则会以传递性依赖的形式自动地引入到项目A中，而无需我们手动显式地在POM文件中声明C依赖来引入。

Maven的传递性依赖机制，大大地减少了人工维护间接依赖的复杂度

传递性依赖的依赖范围

项目A依赖于B组件，B组件依赖于C组件，则我们将A对于B的依赖称之为第一直接依赖，B对于C的依赖称之为第二直接依赖。

根据上文可知，A对于C的依赖是传递性依赖，必要的间接依赖C将通过传递性依赖机制，被自动引入到A中。那么如何判定一个间接依赖是否有必要被引入呢？间接依赖被引入后其依赖范围又是什么呢？

答案其实很简单，就是通过第一直接依赖的依赖范围和第二直接依赖的依赖范围之间的关系，来判定是否有必要引入间接依赖以及确定引入间接依赖后其依赖范围。

如下表所示，若结果为N，则意味着该传递性依赖为非必要的，无需引入；否则，该间接依赖为必要的并自动引入该间接依赖，且引入后该传递依赖的依赖范围如下表单元格中的文字所示

Maven依赖范围不仅控制依赖与classpath的关系，还会影响依赖传递

最左边一列表示第一直接依赖范围，最上面一行表示第二直接依赖范围，中间的交叉单元格则表示传递性依赖范围

compile test provided runtime
compile compile N N runtime
test test N N test
provided provided N provided provided
runtime runtime N N runtime

仔细观察上面表格，我们发现这样的规律

  • 当第二直接依赖的范围是compile的时候，传递性依赖的范围与第一直接依赖的范围一致；
  • 当第二直接依赖的范围是test的时候，依赖不会得以传递；
  • 当第二直接依赖的范围是provided的时候，只传递第一直接依赖的范围也为provided的依赖，切传递性依赖的范围同样为provided；
  • 当第二直接依赖的范围是runtime的时候，传递性依赖的范围与第一直接依赖的范围一致，但compile例外，此时传递性依赖的范围为runtime。

依赖调解

在Maven中由于传递性依赖的机制，一般情况下我们不需要关心间接依赖的管理。

而当间接依赖出问题时，我们需要知道该间接依赖是通过哪条依赖路径引入的，特别是该间接依赖存在多条引入路径时，确定间接依赖引入的路径就显得尤为重要。当一个间接依赖存在多条引入路径时，为避免依赖重复Maven会通过依赖调解来确定该间接依赖的引入路径

依赖调解遵循以下原则，优先使用第一原则，当第一原则无法解决时，则通过第二原则解决

  • 第一原则: 路径最短者优先
  • 第二原则: 第一声明者优先
路径最短者优先

假设在项目A中存在如下依赖关系:

1
2
A -> X -> Y -> Z(2.0)   // dist(A->Z) = 3
A -> M -> Z(2.1)        // dist(A->Z) = 2

项目A依赖的Z组件有2个版本，很显然不可能同时引入两个版本的间接依赖，这里可以看到，Z(2.0)依赖的依赖路径长度为3，Z(2.1)依赖的依赖路径长度为2

根据依赖调解的第一原则——路径最短者优先，所以，2.1版本的Z组件将通过 A -> M -> Z(2.1) 路径被引入到A中

第一声明者优先

假设在项目B中存在如下依赖关系，间接依赖W在两条依赖路径中的路径长度均为2，这时候就无法通过依赖调解的第一原则来确定引入路径。此时需要使用依赖调解的第二原则——第一声明者优先。

根据项目B的POM文件中直接依赖K、P的声明顺序，先声明的直接依赖，则其间接依赖即通过该路径被引入

1
2
B -> K -> W(1.0)        // dist(B->W) = 2
B -> P -> W(2.0)        // dist(B->W) = 2

项目B的POM文件内容如下所示，由于P依赖比K依赖先声明，则2.0版本的的W组件将通过 B -> P -> W(2.0) 路径被引入到B中

1
2
3
4
5
6
7
8
<dependencies>
    <dependency>
        <artifactId>P</artifactId>        
    </dependency>
    <dependency>
        <artifactId>K</artifactId>
    </dependency>
</dependencies>

依赖处理

有时候依赖调解会引入一些不需要的jar，我们可以通过一些方式进行处理

可选依赖 option

可选依赖是通过项目中的POM文件的依赖元素dependency下的option元素中进行配置，只有显式地配置项目中某依赖的option元素为true时，该依赖才是可选依赖；

不设置该元素或值为false时，该依赖即不是可选依赖，其意义在于，当某个间接依赖是可选依赖时，无论依赖范围是什么，其都不会因为传递性依赖机制而被引入

1
2
3
4
5
6
<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.13.2</version>
    <optional>true</optional>
</dependency>

optional元素默认值（false） 当父项目添加junit依赖时，并未添加optional选项，也就是默认的optional元素的值为false。 父项目并未设置optional元素为true，那么便具有依赖传递性。此时，子项目B中会直接引入父项目A中引入的Junit的jar包。也就是说B项目打包时，jar/war包中会包含junit的jar包。

optional元素为true 当父项目引入junit依赖时，设置optional元素为true。那么，子项目B便有了更多的选择。

如果项目B不需要Junit的jar包，那么在其pom文件中不需进行任何处理便可以。如果B项目也需要对应的jar包依赖，可以有两种选择：第一、A项目中对应依赖的optional设置为false或去掉；第二、B项目中直接引入需要的该依赖。

应用场景

这里简单介绍下option元素的实际应用场景

我们在开发项目A的过程中，需要依赖一个第三方持久层的M组件，而这个M组件对两种不同数据库均支持( MySql、Oracle)，故M组件中需要依赖这两种不同数据库的驱动实现——X、Y组件。

对于开发项目A的工程师而言，他可能在项目开发只需要使用其中一种数据库(例如MySql，其驱动实现为X依赖)，如果数据库驱动实现X、Y不是可选依赖，则均会传递到项目A中。

虽然一般情况下这不会引发任何问题，但是会因引入不必要的依赖Y而造成项目体积增大，如果该M组件还支持更多类型的数据库，就会引入更多的不必要的数据库驱动实现依赖进来；而如果M组件中的X、Y依赖是可选依赖的话，则工程师就可以根据实际需要在A项目的POM文件中显式地引入所需数据库的驱动实现依赖即可

使用建议

当然，一般情况下是不推荐使用可选依赖的，使用可选依赖一般是因为项目中支持、实现多种特性所造成的

排除依赖 exclusions
   间接依赖是可以通过传递性依赖机制引入到当前项目中，而有时候第三方组件B的C依赖由于版本(1.0)过低存在安全漏洞。

   我们期望能够将该间接依赖直接剔除出去，不通过传递依赖的形式引入到项目中，这时即可通过exclusions元素实现，该元素下可以包含若干个 exclusion 子元素，然后再在POM中显式地引入合适版本(3.3)的C依赖

image-20230917172717570

在exclusion元素中，只需给定groupId、artifactId即可确定依赖，而无需指定版本version

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<dependencies>
    <dependency>
        <groupId>com.apple</groupId>
        <artifactId>B</artifactId>
        <version>2.3</version>
        <exclusions>
            <exclusion>
                <groupId>com.google</groupId>
                <artifactId>C</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
        <groupId>com.google</groupId>
        <artifactId>C</artifactId>
        <version>3.3</version>        
    </dependency>
</dependencies>

合理的依赖范围

依赖范围：控制依赖与三种classpath的关系，可在POM文件的依赖元素dependency中的scope元素中进行配置，缺省值 compile

Maven在编译、测试、运行(含打包)阶段中所需的依赖并不完全一致，所以Maven通过三种不同的classpath实现在不同阶段引入所需的依赖：编译classpath、测试classpath、运行classpath

常见依赖范围

常见的依赖范围有：

  • compile :

    不声明scope元素的情况下的默认值；compile表示被依赖包需要参与当前项目的编译，包括后续的测试，运行周期也参与其中，是一个比较强的依赖；打包的时候通常需要包含进去。

  • provided :

    provided 类型的scope只会在项目的编译、测试阶段起作用；可以认为在目标容器中已经提供了这个依赖，无需在提供，但是在编写代码或者编译时可能会用到这个依赖；依赖不会被打入到项目jar包中。

  • runtime :

    runtime与compile比较相似，区别在于runtime 跳过了编译阶段，打包的时候通常需要包含进去。

1
2
3
4
5
6
例：当你的代码需要使用jdbc连接一个mysql数据库，通常我们会希望针对标准 JDBC 抽象进行编码，而不是直接错误的使用 MySQL driver实现。这个时候依赖的scope就需要设置为runtime。这意味着我们在编译时无法使用该依赖，该依赖会被包含在最终的产物中，在程序最终执行时可以在classpath下找到它。
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <scope>runtime</scope>
    </dependency>

  • test :

    在一般的编译和运行时都不需要，它们只有在测试编译和测试运行阶段可用，不会被打包到项目jar包中，同时如果项目A依赖于项目B，项目B中的test作用域下的依赖不会被继承。

  • system :

    系统依赖范围，其效果与provided的依赖范围一致。其用于添加非Maven仓库的本地依赖，通过依赖元素dependency中的systemPath元素指定本地依赖的路径。鉴于使用其会导致项目的可移植性降低，一般不推荐使用

1
2
3
4
5
6
7
8
<!--引用-->
<dependency>
    <groupId>xxxx</groupId>
    <artifactId>xxx</artifactId>
    <systemPath>D:\tempare\itheima-maven-test-aaa-1.0-SNAPSHOT.jar</systemPath>
    <scope>system</scope>
    <version>1.4.12</version>
</dependency>

  • import ：

    import 只能在pom文件的中使用，从而引入其他的pom文件中引入依赖，如：在Spring boot 项目的POM文件中，我们可以通过在POM文件中继承 Spring-boot-starter-parent来引用Spring boot默认依赖的jar包，如下：

    1
    2
    3
    4
    5
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.0.1.BUILD-SNAPSHOT</version>
    </parent>

    但是，通过上面的parent继承的方法，只能继承一个 spring-boot-start-parent。实际开发中，用户很可能需要继承自己公司的标准parent配置，这个时候可以使用 scope=import 来实现多继承。代码如下：

    <dependencyManagement>
    <dependencies>
         <dependency>
             <!-- Import dependency management from Spring Boot -->
             <groupId>org.springframework.boot</groupId>
             <artifactId>spring-boot-dependencies</artifactId>
             <version>2.0.1.BUILD-SNAPSHOT</version>
             <type>pom</type>
             <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

    通过上面方式，就可以获取spring-boot-dependencies.2.0.1.BUILD-SNAPSHOT.pom文件中dependencyManagement配置的jar包依赖。如果要继承多个，可以在dependencyManagement中添加，如：

     <dependencyManagement>
     <dependencies>
         <!-- Override Spring Data release train provided by Spring Boot -->
         <dependency>
             <groupId>org.springframework.data</groupId>
             <artifactId>spring-data-releasetrain</artifactId>
             <version>Fowler-SR2</version>
             <type>pom</type>
             <scope>import</scope>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>2.0.1.BUILD-SNAPSHOT</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

依赖关系

依赖范围与三种classpath的关系一览表，如下所示:

依赖范围（scope） 对于编译classpath有效 对于测试classpath有效 对于运行时classpath有效 例子
compile(默认) Y Y Y Spring-core
test N Y N Junit
provided Y Y N servlet-api
runtime N Y Y JDBC驱动实现
system Y Y N 本地的，Maven仓库之外的类库文件

体系外jar包引入

提出问题

『体系外 jar 包』

而实际开发中确实有可能用到一些 jar 包并非是用 Maven 的方式发布，那自然也没法通过 Maven 导入。

此时如果我们能够拿到该 jar 包的源码那还可以自己建一个 Maven 工程，自己打包。可是如果连源码都没有呢？

这方面的例子包括一些人脸识别用的 jar 包、海康视频监控 jar 包等等。

解决办法

准备一个体系外 jar 包

我们通过学 Maven 以前的方式创建一个 Java 工程，然后导出 jar 包即可用来测试。

image-20220701172948395

将该 jar 包安装到 Maven 仓库

这里我们使用 install 插件的 install-file 目标：

1
2
3
4
5
6
7
mvn install:install-file -Dfile=[体系外 jar 包路径] \zdy-spring-boot-starter-1.0-SNAPSHOT.jar
-DgroupId=[给体系外 jar 包强行设定坐标] \
-DartifactId=[给体系外 jar 包强行设定坐标] \
-Dversion=1 \
-Dpackage=jar

mvn deploy:deploy-file -Dfile=文件的位置 -DgroupId=文件groupID  -Dversion=文件的版本号 -Dpackaging=jar -Durl=http://ip地址/nexus/content/repositories/releases -DrepositoryId=releases

例如（Windows 系统下使用 ^ 符号换行；Linux 系统用 \）：

1
2
3
4
5
mvn install:install-file -Dfile=D:\cz_workspace\code\maven_demo\zdy-spring-boot-starter-1.0-SNAPSHOT.jar ^
-DgroupId=com.itheima.maven ^
-DartifactId=zdy-spring-boot-starter ^
-Dversion=1.0 ^
-Dpackaging=jar

执行结果：

image-20220701174936960

再看本地仓库中确实有：

image-20220701175000633

测试

在其它地方依赖这个 jar 包：

1
2
3
4
5
<dependency>
    <groupId>com.itheima.maven</groupId>
    <artifactId>zdy-spring-boot-starter</artifactId>
    <version>1.0</version>
</dependency>

生命周期 & 插件

生命周期

  • Maven的生命周期就是为了对所有的构建过程进行抽象和统一

  • maven把项目的构建划分为不同的生命周期(lifecycle)。粗略一点的话，它这个过程(phase)包括：编译、测试、打包、集成测试、验证、部署。maven中所有的执行动作(goal)都需要指明自己在这个过程中的执行位置，然后maven执行的时候，就依照过程的发展依次调用这些goal进行各种处理。

三套生命周期

下面列出了default、clean和site生命周期的所有构建阶段，这些阶段按照指定的顺序执行。

  1. Clean Lifecycle 在进行真正的构建之前进行一些清理工作
  2. Default Lifecycle 构建的核心部分，编译，测试，打包，部署等等
  3. Site Lifecycle 生成项目报告，站点，发布站点

注意：执行某个生命周期的某个阶段不会影响其它的生命周期！

如果要同时执行多个生命周期的阶段可在命令行输入多个命令，中间以空格隔开，例如： clean package 该命令执行clean生命周期的clean阶段和default生命周期的package阶段。

clean生命周期

包含三个阶段：

1
2
3
1. pre-clean：执行一些清理前需要完成的工作
2. clean：清理上一次构建生成的文件
3. post-clean：执行一些清理后需要完成的工作

default生命周期

default生命周期定义了真正构建时所需要执行的所有步骤，是所有生命周期中最核心的部分

image-20220701181259849

site生命周期

Maven能够基于POM包含的信息，自动生成一个友好的站点，方便团队交流和发布项目信息

1
2
3
4
pre-site：执行一些在生产项目站点前需要完成的工作
site：生成项目站点文档
post-site：执行一些在生产项目站点之后需要完成的工作
site-deploy：将生成的项目站点发布到服务器上

插件

概念

maven插件主要是为maven中生命周期中的阶段服务的，maven中只是定义了3套生命周期，以及每套生命周期中有哪些阶段，具体每个阶段中执行什么操作，完全是交给插件去干。

  • 插件可以通过 mvn 命令的方式调用直接运行
  • 插件与生命周期内的阶段绑定，在执行到对应生命周期时执行对应的插件
  • maven默认在各个生命周期上都绑定了预先设定的插件来完成相应功能

插件通常提供了一个目标的集合，并且可以使用下面的语法执行：

1
<code>mvn [plugin-name]:[goal-name]</code>

例如，一个 Java 工程可以使用 maven-compiler-plugin 的 compile-goal 编译，使用以下命令：

1
<code>mvn compiler:compile</code>

插件目标

maven中的插件以jar的方式存在于仓库中，通过坐标进行访问，每个插件中可能为了代码可以重用，一个插件可能包含了多个功能。插件中的每个功能就叫做插件的目标（Plugin Goal），每个插件中可能包含一个或者多个插件目标（Plugin Goal）。

  • 例如maven-dependency-plugin插件有十多个目标，常见的有dependency:analyze、dependency:tree、dependency:list等不同的功能
  • 列出插件的所有目标：
    • mvn 插件goupId:插件artifactId[:插件version]:help
    • mvn 插件前缀:help

插件前缀

运行插件的时候，可以通过指定插件坐标的方式运行。maven中给插件定义了一些简捷的插件前缀，可以通过插件前缀来运行指定的插件。

可以通过下面命令查看到插件的前缀：mvn help:describe -Dplugin=插件goupId:插件artifactId[:插件version]

1
mvn help:describe -Dplugin=org.apache.maven.plugins:maven-help-plugin

使用mvn命令调用插件的时候，可以使用插件的前缀来代替繁琐的插件坐标的方式。

插件前缀与插件groupId:artifactId是一一对应的关系，这个关系的配置存储在仓库的元数据中

插件和生命周期阶段绑定

将生命周期中的阶段和插件的目标进行绑定的时候，执行 mvn 阶段 就可以执行和这些阶段绑定的 插件目标 。

内置绑定

为了让用户不用任何配置就能构件Maven项目，Maven在核心为一些主要的生命周期阶段绑定了很多插件目标，这些绑定就是内置绑定。下面是三个生命周期中的内置绑定：

image-20220701183531605

default生命周期阶段

image-20220701183544763

自定义绑定
  • 用户可以自己选择将某个插件目标绑定到生命周期的某个阶段上
  • 举例：创建项目的源码jar包，将其安装到仓库中，我们将maven-source-plugin插件中的jar-no-fork目标绑定到default生命周期的verify阶段上，这样就可以将项目的主代码打包成jar文件
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-source-plugin</artifactId>
            <version>3.2.1</version>
            <executions>
                <!-- 使用插件需要执行的任务 -->
                <execution>
                     <!-- 任务id -->
                    <id>attach-sources</id>
                    <!-- 绑定的阶段 -->
                    <phase>verify</phase>
                     <!-- 任务中插件的目标，可以指定多个 -->
                    <goals>
                        <goal>jar-no-fork</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>
运行命令：mvn install

插件配置

命令行插件配置

用户可以在Maven命令中使用-D参数，并伴随一个参数键 = 参数值的形式，来配置插件目标的参数，例如，maven-surefire-plugin提供了一个maven.test.skip参数，当其值为true的时候，跳过执行测试

1
$mvn install -Dmaven.test.skip = true  //参数-D是Java自带的

POM中插件全局配置

用户可以在声明插件的时候，对插件进行一个全局的配置，也就是说，所有基于该插件目标的任务，都会使用这些配置。例如，配置maven-compiler-plugin告诉它编译Java1.5的源文件，生成与JVM1.5兼容的字节码文件，如下

1
2
3
4
5
6
7
8
9
10
11
12
13
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.1</version>
            <configuration>
                <source>1.5</source>
                <target>1.5</target>
            </configuration>
        </plugin>
    </plugins>
</build>

依赖纠错

由于实际开发时我们往往都会整合使用很多大型框架，所以一个项目中哪怕只是一个模块也会涉及到大量 jar 包。数以百计的 jar 包要彼此协调、精密配合才能保证程序正常运行。而规模如此庞大的 jar 包组合在一起难免会有磕磕碰碰。最关键的是由于 jar 包冲突所导致的问题非常诡异，这里我们只能罗列较为典型的问题，而没法保证穷举。

但是我们仍然能够指出一点：一般来说，由于我们自己编写代码、配置文件写错所导致的问题通常能够在异常信息中看到我们自己类的全类名或配置文件的所在路径。如果整个错误信息中完全没有我们负责的部分，全部是框架、第三方工具包里面的类报错，这往往就是 jar 包的问题所引起的。

而具体的表现形式中，主要体现为找不到类或找不到方法。

  • java.lang.ClassNotFoundException：编译过程中找不到类
  • java.lang.NoClassDefFoundError：运行过程中找不到类
  • java.lang.NoSuchMethodError

分析解决

很多情况下常用框架之间的整合容易出现的冲突问题都有人总结过了，拿抛出的异常搜索一下基本上就可以直接找到对应的 jar 包。我们接下来要说的是通用方法。

不管具体使用的是什么工具，基本思路无非是这么两步：

  • 第一步：把彼此冲突的 jar 包找到
  • 第二步：在冲突的 jar 包中选定一个。具体做法无非是通过 exclusions 排除依赖，或是明确声明依赖。

IDEA 的 Maven Helper 插件

这个插件是 IDEA 中安装的插件，不是 Maven 插件。它能够给我们罗列出来同一个 jar 包的不同版本，以及它们的来源

image-20220701185347742

image-20220701185452212

其中三个选项分别表示如下:

  1. Conflicts（查看冲突）
  2. All Dependencies as List（列表形式查看所有依赖）
  3. All Dependencies as Tree（树形式查看所有依赖）

image-20220701185505856

2、IEDA使用Maven命令查看依赖冲突方法

①：想要查看maven的依赖树的时候使用Maven命令来查看依赖：

maven dependency:tree

②：查看是否有依赖冲突也可以使用Maven命令来查看：

mvn dependency:tree -Dverbose -Dincludes=:

问题

maven下载依赖中途失败解决

今天又遇到了这个问题：dependency冲突问题，看了一下，知道是因为之前WiFi突然断掉，jar包没有下载成功。
以前只有一个jar包，直接到对应的目录下删除lastupload结尾的文件，maven upload就可以了。
但是很多jar包时候就不方便了，解决办法：clean intall -U

Bigint 相当于java里面的long

maven项目pom文件有删除线解决办法

项目中不知道操作了什么，造成一个maven模块不能被识别

image-20220717140648338

解决办法，打开preference，按照如下图方式找到对应的模块，去掉前面的钩即可

image-20220717140657713

maven loading archetype list以及加载archetype.xml很慢

image-20220717140727483

MAVEN 项目卡在 Generating project in Batch mode

IDEA 创建 MAVEN 项目卡在 Generating project in Batch mode。是 MAVEN 一直在请求：http://repo1.maven.org/maven2/archetype-catalog.xml

这个项目目录的 xml 文件，由于墙的问题，加载缓慢，等待时间十分漫长。解决方法：修改 setting.xml 文件，把 mirror 改成阿里的镜像。

1、打开 maven 目录下的 conf/setting.xml，注意要是 idea 使用的 maven。

2、搜索 <mirrors>；找到<mirrors>。在 <mirrors> 节点下添加。

1
2
3
4
5
6
<mirror>
      <id>alimaven</id>
      <name>aliyun maven</name>
      <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
      <mirrorOf>central</mirrorOf>        
</mirror>

3、运行 MVN 命令的时候加上 -DarchetypeCatalog=local 这个参数。在 IDEA 中：

image-20220717141351009

maVen 3.8 https问题

Since Maven 3.8.1 http repositories are blocked.

Downgrade Maven to version 3.8.1 or earlier in settings

自版本 3.8.1 起，Maven 默认阻止外部 HTTP 存储库

解决办法：修改settings.xml中下面的配置为false

1
2
3
4
5
6
7
<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>