Maven on Logan的博客

maven概述

Sun, 03 Mar 2024 12:49:51 +0800

http://heavy_code_industry.gitee.io/code_heavy_industry/

https://maven.apache.org/index.html

https://mvnrepository.com/

https://www.bilibili.com/video/BV12q4y147e4?spm_id_from=333.337.search-card.all.click

1、maven介绍

①、概述

Maven 是一款『构建管理』和『依赖管理』的工具。但事实上这只是 Maven 的一部分功能。Maven 本身的产品定位是一款『项目管理工具』

②、maven工作机制

maven仓库里有：自己项目打包成的jar、第三方jar、maven核心程序需要用到的插件jar（clean、test、package）

③、功能

从『项目管理』的角度来看，Maven 提供了如下这些功能：

项目对象模型（POM）：将整个项目本身抽象、封装为应用程序中的一个对象，以便于管理和操作。
全局性构建逻辑重用：Maven 对整个构建过程进行封装之后，程序员只需要指定配置信息即可完成构建。让构建过程从 Ant 的『编程式』升级到了 Maven 的『声明式』。
构件的标准集合：在 Maven 提供的标准框架体系内，所有的构件都可以按照统一的规范生成和使用。
构件关系定义：Maven 定义了构件之间的三种基本关系，让大型应用系统可以使用 Maven 来进行管理
- 继承关系：通过从上到下的继承关系，将各个子构件中的重复信息提取到父构件中统一管理
- 聚合关系：将多个构件聚合为一个整体，便于统一操作
- 依赖关系：Maven 定义了依赖的范围、依赖的传递、依赖的排除、版本仲裁机制等一系列规范和标准，让大型项目可以有序容纳数百甚至更多依赖
插件目标系统：Maven 核心程序定义抽象的生命周期，然后将插件的目标绑定到生命周期中的特定阶段，实现了标准和具体实现解耦合，让 Maven 程序极具扩展性
项目描述信息的维护：我们不仅可以在 POM 中声明项目描述信息，更可以将整个项目相关信息收集起来生成 HTML 页面组成的一个可以直接访问的站点。这些项目描述信息包括：
- 公司或组织信息 organization
- 项目许可证 licenses
- 开发成员信息 developers
- issue 管理信息 issueManagement
- SCM 信息 scm 远程仓库支持

④、maven坐标

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

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

三个向量的取值方式

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

2、POM介绍

①、含义

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

②、模型化思想

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

③、pom标签

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

下面是 spring-boot-starter 的 POM 文件，可以看到：除了我们熟悉的坐标标签、dependencies 标签，还有 description、url、organization、licenses、developers、scm、issueManagement 等这些描述项目信息的标签。

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter</artifactId>
  <version>2.5.6</version>
  <name>spring-boot-starter</name>
  <description>Core starter, including auto-configuration support, logging and YAML</description>
  <url>https://spring.io/projects/spring-boot</url>
  <organization>
    <name>Pivotal Software, Inc.</name>
    <url>https://spring.io</url>
  </organization>
  <licenses>
    <license>
      <name>Apache License, Version 2.0</name>
      <url>https://www.apache.org/licenses/LICENSE-2.0</url>
    </license>
  </licenses>
  <developers>
    <developer>
      <name>Pivotal</name>
      <email>info@pivotal.io</email>
      <organization>Pivotal Software, Inc.</organization>
      <organizationUrl>https://www.spring.io</organizationUrl>
    </developer>
  </developers>
  <scm>
    <connection>scm:git:git://github.com/spring-projects/spring-boot.git</connection>
    <developerConnection>scm:git:ssh://git@github.com/spring-projects/spring-boot.git</developerConnection>
    <url>https://github.com/spring-projects/spring-boot</url>
  </scm>
  <issueManagement>
    <system>GitHub</system>
    <url>https://github.com/spring-projects/spring-boot/issues</url>
  </issueManagement>

  <dependencies>
    <dependency>
      ……
    </dependency>
  </dependencies>
</project>

Copied!

3、POM的四个层次

①、超级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 类。
位置：${MAVEN_HOME}/lib/maven-model-builder-3.5.0.jar里面 org\apache\maven\model\pom-4.0.0.xml

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

<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.
-->

<!-- START SNIPPET: superpom -->
<project>
  <modelVersion>4.0.0</modelVersion>

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

  <pluginRepositories>
    <pluginRepository>
      <id>central</id>
      <name>Central Repository</name>
      <url>https://repo.maven.apache.org/maven2</url>
      <layout>default</layout>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
      <releases>
        <updatePolicy>never</updatePolicy>
      </releases>
    </pluginRepository>
  </pluginRepositories>

  <build>
    <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>
    </testResources>
    <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) -->
      <plugins>
        <plugin>
          <artifactId>maven-antrun-plugin</artifactId>
          <version>1.3</version>
        </plugin>
        <plugin>
          <artifactId>maven-assembly-plugin</artifactId>
          <version>2.2-beta-5</version>
        </plugin>
        <plugin>
          <artifactId>maven-dependency-plugin</artifactId>
          <version>2.8</version>
        </plugin>
        <plugin>
          <artifactId>maven-release-plugin</artifactId>
          <version>2.5.3</version>
        </plugin>
      </plugins>
    </pluginManagement>
  </build>

  <reporting>
    <outputDirectory>${project.build.directory}/site</outputDirectory>
  </reporting>

  <profiles>
    <!-- NOTE: The release profile will be removed from future versions of the super POM -->
    <profile>
      <id>release-profile</id>

      <activation>
        <property>
          <name>performRelease</name>
          <value>true</value>
        </property>
      </activation>

      <build>
        <plugins>
          <plugin>
            <inherited>true</inherited>
            <artifactId>maven-source-plugin</artifactId>
            <executions>
              <execution>
                <id>attach-sources</id>
                <goals>
                  <goal>jar-no-fork</goal>
                </goals>
              </execution>
            </executions>
          </plugin>
          <plugin>
            <inherited>true</inherited>
            <artifactId>maven-javadoc-plugin</artifactId>
            <executions>
              <execution>
                <id>attach-javadocs</id>
                <goals>
                  <goal>jar</goal>
                </goals>
              </execution>
            </executions>
          </plugin>
          <plugin>
            <inherited>true</inherited>
            <artifactId>maven-deploy-plugin</artifactId>
            <configuration>
              <updateReleaseInfo>true</updateReleaseInfo>
            </configuration>
          </plugin>
        </plugins>
      </build>
    </profile>
  </profiles>

</project>
<!-- END SNIPPET: superpom -->

Copied!

②、父POM

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

③、有效 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：这一层可能没有，可能有一层，也可能有很多层。
当前 pom.xml 配置的 POM：我们最多关注和最多使用的一层。
有效 POM：隐含的一层，但是实际上真正生效的一层。

4、生命周期

①、构建过程

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

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

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

②、三个生命周期

生命周期名称	作用	各个环节
Clean	清理操作相关	pre-clean clean post-clean
Site	生成站点相关	pre-site site post-site deploy-site
Default	主要构建过程	validate generate-sources process-sources generate-resources process-resources 复制并处理资源文件，至目标目录，准备打包。 compile 编译项目 main 目录下的源代码。 process-classes generate-test-sources process-test-sources generate-test-resources process-test-resources 复制并处理资源文件，至目标测试目录。 test-compile 编译测试源代码。 process-test-classes test 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。 prepare-package package 接受编译好的代码，打包成可发布的格式，如JAR。 pre-integration-test integration-test post-integration-test verify install将包安装至本地仓库，以让其它项目依赖。 deploy将最终的包复制到远程的仓库，以让其它开发人员共享；或者部署到服务器上运行（需借助插件，例如：cargo）。

③、特点

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

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

5、仓库和镜像

①、仓库

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

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

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

②、镜像

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

将下面 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>

Copied!

6、约定的目录结构

①、各个目录的作用

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

②、约定目录结构的意义

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

③、约定大于配置

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

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

7、依赖的配置

①、依赖的范围scope

标签的位置：dependencies/dependency/scope

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

compile 和 test 对比

	main目录（空间）	test目录（空间）	开发过程（时间）	部署到服务器（时间）
compile	有效	有效	有效	有效
test	无效	有效	有效	无效

compile 和 provided 对比

	main目录（空间）	test目录（空间）	开发过程（时间）	部署到服务器（时间）
compile	有效	有效	有效	有效
provided	有效	有效	有效	无效

结论

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

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

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

test scope 在springboot里不会参与打包，runtime provided会打进包里

②、依赖的传递性

概念

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

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

B 依赖 C 时使用 compile 范围：可以传递

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

③、依赖的排除

概念

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

所以配置依赖的排除其实就是阻止某些 jar 包的传递。因为这样的 jar 包传递过来会和其他 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>

Copied!

④、scope-import

管理依赖最基本的办法是继承父工程，但是和 Java 类一样，Maven 也是单继承的。如果不同体系的依赖信息封装在不同 POM 中了，没办法继承多个父工程怎么办？这时就可以使用 import 依赖范围。

典型案例当然是在项目中引入 SpringBoot、SpringCloud 依赖：

<dependencyManagement>
    <dependencies>

        <!-- SpringCloud 依赖导入 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>Hoxton.SR9</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>

        <!-- SpringCloud Alibaba 依赖导入 -->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-alibaba-dependencies</artifactId>
            <version>2.2.6.RELEASE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>

        <!-- SpringBoot 依赖导入 -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>2.3.6.RELEASE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Copied!

import 依赖范围使用要求：

打包类型必须是 pom
必须放在 dependencyManagement 中

官网说明如下：

This scope is only supported on a dependency of type pom in the <dependencyManagement>section. It indicates the dependency is to be replaced with the effective list of dependencies in the specified POM’s <dependencyManagement> section. Since they are replaced, dependencies with a scope of import do not actually participate in limiting the transitivity of a dependency.

⑤、scope-system

以 Windows 系统环境下开发为例，假设现在 D:\tempare\atguigu-maven-test-aaa-1.0-SNAPSHOT.jar 想要引入到我们的项目中，此时我们就可以将依赖配置为 system 范围：

<dependency>
    <groupId>com.atguigu.maven</groupId>
    <artifactId>atguigu-maven-test-aaa</artifactId>
    <version>1.0-SNAPSHOT</version>
    <systemPath>D:\tempare\atguigu-maven-test-aaa-1.0-SNAPSHOT.jar</systemPath>
    <scope>system</scope>
</dependency>

Copied!

但是很明显：这样引入依赖完全不具有可移植性，所以不要使用。如果需要引入体系外 jar 包我们后面会讲专门的办法。

⑥、scope-runtime

专门用于编译时不需要，但是运行时需要的 jar 包。比如：编译时我们根据接口调用方法，但是实际运行时需要的是接口的实现类。典型案例是：

<!--热部署 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-devtools</artifactId>
    <scope>runtime</scope>
    <optional>true</optional>
</dependency>

Copied!

会参与依赖传递

⑦、optional

配置

<!--热部署 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-devtools</artifactId>
    <scope>runtime</scope>
    <optional>true</optional>
</dependency>

Copied!

runtime true

正常一个依赖加上这两个配置之后不影响springboot打包，但是springboot打包时没有包括spring-boot-devtools

应该是springboot自己做了处理

optional本质含义

可选其实就是『可有可无』。官网的解释是：

其核心含义是：Project X 依赖 Project A，A 中一部分 X 用不到的代码依赖了 B，那么对 X 来说 B 就是『可有可无』的。

optional不会参与依赖传递

⑧、依赖的版本仲裁

最短路径优先

在下图的例子中，对模块 pro25-module-a 来说，Maven 会采纳 1.2.12 版本。

路径相同时先声明者优先

此时 Maven 采纳哪个版本，取决于在 pro29-module-x 中，对 pro30-module-y 和 pro31-module-z 两个模块的依赖哪一个先声明。

其实 Maven 的版本仲裁机制只是在没有人为干预的情况下，自主决定 jar 包版本的一个办法。而实际上我们要使用具体的哪一个版本，还要取决于项目中的实际情况。所以在项目正常运行的情况下，jar 包版本可以由 Maven 仲裁，不必我们操心；而发生冲突时 Maven 仲裁决定的版本无法满足要求，此时就应该由程序员明确指定 jar 包版本。

8、继承

①、概念

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

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

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

只有打包方式为pom的工程才能作为父工程

②、作用

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

它的背景是：

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

它背后的需求是：

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

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

9、聚合

①、聚合本身的含义

部分组成整体

动画片《战神金刚》中的经典台词：“我来组成头部！我来组成手臂！”就是聚合关系最生动的体现。

②、Maven 中的聚合

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

项目：整体
模块：部分

TIP

概念的对应关系：

从继承关系角度来看：

父工程

子工程

从聚合关系角度来看：

总工程

模块工程

③、好处

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

以 mvn install 命令为例：Maven 要求有父工程时先安装父工程；有依赖的工程时，先安装被依赖的工程。我们自己考虑这些规则会很麻烦。但是工程聚合之后，在总工程执行 mvn install 可以一键完成安装，而且会自动按照正确的顺序执行。
配置聚合之后，各个模块工程会在总工程中展示一个列表，让项目中的各个模块一目了然。

④、聚合的配置

在总工程中配置 modules 即可：

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

Copied!

⑤、依赖循环问题

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

DANGER

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

这个错误的含义是：循环引用。

10、定义jdk版本和编码

①、直接使用默认取值

<properties>
      	<!-- maven-resources-plugin和maven-compiler-plugin插件的默认取值 -->
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  
  			<!-- maven-site-plugin等插件的默认取值 -->
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
      
      	<!-- maven-compiler-plugin插件的默认取值 -->
      	<maven.compiler.source>1.8</maven.compiler.source>
    		<maven.compiler.target>1.8</maven.compiler.target>
      
      	<!-- spring-boot-starter-parent里定义的的默认取值 -->
        <java.version>1.8</java.version>
      
</properties>

Copied!

②、或者在插件中定义

<project>
  [...]
  <build>
    [...]
    <plugins>
      
      <!-- JDK版本 -->
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.10.1</version>
        <configuration>
          <source>1.8</source>
          <target>1.8</target>
          <encoding>UTF-8</encoding>
        </configuration>
      </plugin>
    
    	<!-- 编码 -->
   		<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-resources-plugin</artifactId>
        <version>3.2.0</version>
        <configuration>
          ...
          <encoding>UTF-8</encoding>
          ...
        </configuration>
      </plugin>
      
      
      
    </plugins>
    [...]
  </build>
  [...]
</project>

Copied!

③、或写在超级pom里，全局设定

配置的方式是：将 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>

Copied!

不推荐,仅在本地生效，如果脱离当前的settings.xml能够覆盖的范围，则无法生效

11、属性的声明与引用

①、help 插件的各个目标

官网说明地址：https://maven.apache.org/plugins/maven-help-plugin

目标	说明
help:active-profiles	列出当前已激活的 profile
help:all-profiles	列出当前工程所有可用 profile
help:describe	描述一个插件和/或 Mojo 的属性
help:effective-pom	以 XML 格式展示有效 POM
help:effective-settings	为当前工程以 XML 格式展示计算得到的 settings 配置
help:evaluate	计算用户在交互模式下给出的 Maven 表达式
help:system	显示平台详细信息列表，如系统属性和环境变量

②、使用help:evaluate查看属性值

定义属性

1
2
3

<properties>
    <com.atguigu.hello>good morning maven</com.atguigu.hello>
</properties>

Copied!

运行 mvn help:evaluate

③、通过 Maven 访问系统属性

java属性一览

Properties properties = System.getProperties();
Set<Object> propNameSet = properties.keySet();
for (Object propName : propNameSet) {
    String propValue = properties.getProperty((String) propName);
    System.out.println(propName + " = " + propValue);
}

Copied!

java.runtime.name = Java(TM) SE Runtime Environment sun.boot.library.path = D:\software\Java\jre\bin java.vm.version = 25.141-b15 java.vm.vendor = Oracle Corporation java.vendor.url = http://java.oracle.com/

…………

使用 Maven 访问系统属性

访问系统环境变量

访问 project 属性

使用表达式 ${project.xxx} 可以访问当前 POM 中的元素值。

访问一级标签:

${project.标签名}

访问子标签:

${project.标签名.子标签名}

访问列表标签:

${project.标签名[下标]}

访问 settings 全局配置

${settings.标签名} 可以访问 settings.xml 中配置的元素值。

④、用途

在当前 pom.xml 文件中引用属性
资源过滤功能：在非 Maven 配置文件中引用属性，由 Maven 在处理资源时将引用属性的表达式替换为属性值

创建待处理的资源文件

dev.user=${dev.jdbc.user}
dev.password=${dev.jdbc.password}
dev.url=${dev.jdbc.url}
dev.driver=${dev.jdbc.driver}

Copied!

配置 profile

<profiles>
    <profile>
        <id>devJDBCProfile</id>
        <properties>
            <dev.jdbc.user>root</dev.jdbc.user>
            <dev.jdbc.password>atguigu</dev.jdbc.password>
            <dev.jdbc.url>http://localhost:3306/db_good</dev.jdbc.url>
            <dev.jdbc.driver>com.mysql.jdbc.Driver</dev.jdbc.driver>
        </properties>
        <build>
            <resources>
                <resource>
                    <!-- 表示为这里指定的目录开启资源过滤功能 -->
                    <directory>src/main/resources</directory>

                    <!-- 将资源过滤功能打开 -->
                    <filtering>true</filtering>
                </resource>
            </resources>
        </build>
    </profile>
</profiles>

Copied!

执行处理资源命令

`1`	`mvn clean resources:resources -PdevJDBCProfile`

Copied!

12、profile详解

①、profile 概述

[1] 单词释义

这里我们可以对接 profile 这个单词中『侧面』这个含义：项目的每一个运行环境，相当于是项目整体的一个侧面。

[2] 项目的不同运行环境

通常情况下，我们至少有三种运行环境：

开发环境：供不同开发工程师开发的各个模块之间互相调用、访问；内部使用
测试环境：供测试工程师对项目的各个模块进行功能测试；内部使用
生产环境：供最终用户访问——所以这是正式的运行环境，对外提供服务

而我们这里的『环境』仍然只是一个笼统的说法，实际工作中一整套运行环境会包含很多种不同服务器：

MySQL
Redis
ElasticSearch
RabbitMQ
FastDFS
Nginx
Tomcat
……

就拿其中的 MySQL 来说，不同环境下的访问参数肯定完全不同：

开发环境	测试环境	生产环境
dev.driver=com.mysql.jdbc.Driver dev.url=jdbc:mysql://124.71.36.17:3306/db-sys dev.username=root dev.password=atguigu	test.driver=com.mysql.jdbc.Driver test.url=jdbc:mysql://124.71.36.89:3306/db-sys test.username=dev-team test.password=atguigu	product.driver=com.mysql.jdbc.Driver product.url=jdbc:mysql://39.107.88.164:3306/prod-db-sys product.username=root product.password=atguigu

可是代码只有一套。如果在 jdbc.properties 里面来回改，那就太麻烦了，而且很容易遗漏或写错，增加调试的难度和工作量。所以最好的办法就是把适用于各种不同环境的配置信息分别准备好，部署哪个环境就激活哪个配置。

在 Maven 中，使用 profile 机制来管理不同环境下的配置信息。但是解决同类问题的类似机制在其他框架中也有，而且从模块划分的角度来说，持久化层的信息放在构建工具中配置也违反了『高内聚，低耦合』的原则。

所以 Maven 的 profile 我们了解一下即可，不必深究。

[3] profile 声明和使用的基本逻辑

首先为每一个环境声明一个 profile
- 环境 A：profile A
- 环境 B：profile B
- 环境 C：profile C
- ……
然后激活某一个 profile

[4] 默认 profile

其实即使我们在 pom.xml 中不配置 profile 标签，也已经用到 profile了。为什么呢？因为根标签 project 下所有标签相当于都是在设定默认的 profile。这样一来我们也就很容易理解下面这句话：project 标签下除了 modelVersion 和坐标标签之外，其它标签都可以配置到 profile 中。

②、profile 配置

[1] 外部视角：配置文件

从外部视角来看，profile 可以在下面两种配置文件中配置：

settings.xml：全局生效。其中我们最熟悉的就是配置 JDK 1.8。

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

Copied!

pom.xml：当前 POM 生效

[2] 内部实现：具体标签

从内部视角来看，配置 profile 有如下语法要求：

profiles/profile 标签

由于 profile 天然代表众多可选配置中的一个所以由复数形式的 profiles 标签统一管理。

由于 profile 标签覆盖了 pom.xml 中的默认配置，所以 profiles 标签通常是 pom.xml 中的最后一个标签。
id 标签

每个 profile 都必须有一个 id 标签，指定该 profile 的唯一标识。这个 id 标签的值会在命令行调用 profile 时被用到。这个命令格式是：-D。
其它允许出现的标签

一个 profile 可以覆盖项目的最终名称、项目依赖、插件配置等各个方面以影响构建行为。

build

defaultGoal

finalName

resources

testResources

plugins

reporting

modules

dependencies

dependencyManagement

repositories

pluginRepositories

properties

③、激活 profile

[1] 默认配置默认被激活

前面提到了，POM 中没有在 profile 标签里的就是默认的 profile，当然默认被激活。

[2] 基于环境信息激活

环境信息包含：JDK 版本、操作系统参数、文件、属性等各个方面。一个 profile 一旦被激活，那么它定义的所有配置都会覆盖原来 POM 中对应层次的元素。可以参考下面的标签结构：

<profile>
	<id>dev</id>
    <activation>
        <!-- 配置是否默认激活 -->
    		<activeByDefault>false</activeByDefault>
      
      	<!-- 配置激活条件 -->
        <jdk>1.5</jdk>
        <os>
        	<name>Windows XP</name>
            <family>Windows</family>
            <arch>x86</arch>
            <version>5.1.2600</version>
        </os>
        <property>
        	<name>mavenVersion</name>
            <value>2.0.5</value>
        </property>
        <file>
        	<exists>file2.properties</exists>
            <missing>file1.properties</missing>
        </file>
    </activation>
</profile>

Copied!

这里有个问题是：多个激活条件之间是什么关系呢？

Maven 3.2.2 之前：遇到第一个满足的条件即可激活——或的关系。
Maven 3.2.2 开始：各条件均需满足——且的关系。

下面我们来看一个具体例子。假设有如下 profile 配置，在 JDK 版本为 1.6 时被激活：

<profiles>
	<profile>
    	<id>JDK1.6</id>
        <activation>
            <!-- 指定激活条件为：JDK 1.6 -->
        	<jdk>1.6</jdk>
        </activation>
        ……
    </profile>
</profiles>

Copied!

这里需要指出的是：Maven 会自动检测当前环境安装的 JDK 版本，只要 JDK 版本是以 1.6 开头都算符合条件。下面几个例子都符合：

1.6.0_03
1.6.0_02
……

[3] 命令行激活

列出活动的 profile

1
2

# 列出所有激活的 profile，以及它们在哪里定义
mvn help:active-profiles

Copied!

指定某个具体 profile

`1`	`mvn compile -P<profile id>`

Copied!

④、操作举例

[1] 编写 Lambda 表达式代码

Lambda 表达式代码要求 JDK 版本必须是 1.8，我们可以以此来判断某个指定更低 JDK 版本的 profile 是否被激活生效。

@Test
public void test() {
    new Thread(()->{
        System.out.println(Thread.currentThread().getName() + " is working");
    }).start();
}

Copied!

以目前配置运行这个测试方法：

[2] 配置 profile

<profiles>
    <profile>
        <id>myJDKProfile</id>
        <!-- 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.6</source>
                        <target>1.6</target>
                        <encoding>UTF-8</encoding>
                    </configuration>
                </plugin>
            </plugins>
        </build>
    </profile>
</profiles>

Copied!

[3] 执行构建命令

`1`	`mvn clean test -PmyJDKProfile`

Copied!

⑤、资源属性过滤

[1] 简介

Maven 为了能够通过 profile 实现各不同运行环境切换，提供了一种『资源属性过滤』的机制。通过属性替换实现不同环境使用不同的参数。

[2] 操作演示

配置 profile

<profiles>
    <profile>
        <id>devJDBCProfile</id>
        <properties>
            <dev.jdbc.user>root</dev.jdbc.user>
            <dev.jdbc.password>atguigu</dev.jdbc.password>
            <dev.jdbc.url>http://localhost:3306/db_good</dev.jdbc.url>
            <dev.jdbc.driver>com.mysql.jdbc.Driver</dev.jdbc.driver>
        </properties>
        <build>
            <resources>
                <resource>
                    <!-- 表示为这里指定的目录开启资源过滤功能 -->
                    <directory>src/main/resources</directory>

                    <!-- 将资源过滤功能打开 -->
                    <filtering>true</filtering>
                </resource>
            </resources>
        </build>
    </profile>
</profiles>

Copied!

创建待处理的资源文件

dev.user=${dev.jdbc.user}
dev.password=${dev.jdbc.password}
dev.url=${dev.jdbc.url}
dev.driver=${dev.jdbc.driver}

Copied!

执行处理资源命令

`1`	`mvn clean resources:resources -PdevJDBCProfile`

Copied!

找到处理得到的资源文件

延伸

我们时不时会在 resource 标签下看到 includes 和 excludes 标签。它们的作用是：

includes：指定执行 resource 阶段时要包含到目标位置的资源
excludes：指定执行 resource 阶段时要排除的资源

情看下面的例子：

<build>
    <resources>
        <resource>
            <!-- 表示为这里指定的目录开启资源过滤功能 -->
            <directory>src/main/resources</directory>

            <!-- 将资源过滤功能打开 -->
            <filtering>true</filtering>

            <includes>
                <include>*.properties</include>
            </includes>

            <excludes>
                <exclude>happy.properties</exclude>
            </excludes>
        </resource>
    </resources>
</build>

Copied!

执行处理资源命令：

`1`	`mvn clean resources:resources -PdevJDBCProfile`

Copied!

执行效果如下：

当然我们这里只是以 properties 文件为例，并不是只能处理 properties 文件。

1普通工程-命令行

Sun, 03 Mar 2024 13:49:51 +0800

一、创建 Maven 工程

1、使用命令生成Maven工程

在工作目录打开命令行

运行 mvn archetype:generate 命令

下面根据提示操作

TIP

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

Define value for property ‘groupId’: com.atguigu.maven

Define value for property ‘artifactId’: pro01-maven-java

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 再回车。】

2、调整

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

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

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

Copied!

3、自动生成的 pom.xml 解读

	<!-- modelVersion 标签：从maven2 开始就是固定为 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>
	<!-- 工程构建过程中读取源码时使用的字符集 -->
    <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>

Copied!

二、编写代码

1、主体程序

主体程序指的是被测试的程序，同时也是将来在项目中真正要使用的程序。

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

Copied!

2、测试程序

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);
		
	}
	
}

Copied!

三、执行maven构建

1、要求

运行 Maven 中和构建操作相关的命令时，必须进入到 pom.xml 所在的目录。如果没有在 pom.xml 所在的目录运行 Maven 的构建命令，那么会看到下面的错误信息：

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

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

2、清理操作

mvn clean

效果：删除 target 目录

3、编译操作

主程序编译：mvn compile

测试程序编译：mvn test-compile

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

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

4、测试操作

mvn test

测试的报告存放的目录：target/surefire-reports

5、打包操作

mvn package

打包的结果——jar 包，存放的目录：target

并没有把依赖的包（maven dependency）一起打在生成的jar包里，这里的打jar包，实际maven认为是一个工具包，是一个后面被项目继续依赖的包，所以没必要把依赖的包打进去。

如果需要生成一个可执行的包，则需要用maven插件：

<plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <version>2.4</version>
                <configuration>
                    <archive>
                        <manifest>
                            <useUniqueVersions>false</useUniqueVersions>
                            <addClasspath>true</addClasspath>
                            <classpathPrefix>lib/</classpathPrefix>
                            <mainClass>com.wyz.Main</mainClass>
                        </manifest>
                    </archive>
                </configuration>
</plugin>

Copied!

<plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-dependency-plugin</artifactId>
                <executions>
                    <execution>
                        <id>copy-dependencies</id>
                        <phase>package</phase>
                        <goals>
                            <goal>copy-dependencies</goal>
                        </goals>
                        <configuration>
                            <!-- 拷贝项目依赖包到lib/目录下 -->
                            <outputDirectory>${project.build.directory}/lib</outputDirectory>
                            <!-- 间接依赖也拷贝 -->
                            <excludeTransitive>false</excludeTransitive>
                            <!-- 带上版本号 -->
                            <stripVersion>false</stripVersion>
                        </configuration>
                    </execution>
                </executions>
</plugin>

Copied!

把依赖也打进jar包：mainClass是jar包的main方法入口:

<build>
        <plugins>
            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <configuration>
                    <archive>
                        <manifest>
                            <mainClass>com.wyz.Main</mainClass>
                        </manifest>
                    </archive>
                    <descriptorRefs>
                        <descriptorRef>jar-with-dependencies</descriptorRef>
                    </descriptorRefs>
                </configuration>
            </plugin>
        </plugins>
    </build>

Copied!

6、安装操作

mvn install

1
2

[INFO] Installing D:\maven-workspace\space201026\pro01-maven-java\target\pro01-maven-java-1.0-SNAPSHOT.jar to D:\maven-rep1026\com\atguigu\maven\pro01-maven-java\1.0-SNAPSHOT\pro01-maven-java-1.0-SNAPSHOT.jar
[INFO] Installing D:\maven-workspace\space201026\pro01-maven-java\pom.xml to D:\maven-rep1026\com\atguigu\maven\pro01-maven-java\1.0-SNAPSHOT\pro01-maven-java-1.0-SNAPSHOT.pom

Copied!

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

坐标信息如下：

1
2
3

 <groupId>com.atguigu.maven</groupId>
  <artifactId>pro01-maven-java</artifactId>
  <version>1.0-SNAPSHOT</version>

Copied!

在 Maven 仓库中生成的路径如下：

maven\repository\com\atguigu\maven\pro01-maven-java\1.0-SNAPSHOT\pro01-maven-java-1.0-SNAPSHOT.jar

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

2 web工程-命令行

Sun, 03 Mar 2024 14:49:51 +0800

一、创建web工程

1、说明

使用 mvn archetype:generate 命令生成 Web 工程时，需要使用一个专门的 archetype。这个专门生成 Web 工程骨架的 archetype 可以参照官网看到它的用法：

参数 archetypeGroupId、archetypeArtifactId、archetypeVersion 用来指定现在使用的 maven-archetype-webapp 的坐标。

2、操作

注意：如果在上一个工程的目录下执行 mvn archetype:generate 命令，那么 Maven 会报错：不能在一个非 pom 的工程下再创建其他工程。所以不要再刚才创建的工程里再创建新的工程，请回到工作空间根目录来操作。

然后运行生成工程的命令：

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

Copied!

下面的操作按照提示执行：

TIP 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: :【直接回车，表示确认】

3、生成的pom.xml

确认打包的方式是war包形式

war

4、生成的Web工程的目录结构

webapp 目录下有 index.jsp

WEB-INF 目录下有 web.xml

5、创建 Servlet

①在 main 目录下创建 java 目录

②在 java 目录下创建 Servlet 类所在的包的目录

③在包下创建 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");
		
	}
	
}

Copied!

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

Copied!

6、在 index.jsp 页面编写超链接

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

Copied!

TIP JSP全称是 Java Server Page，和 Thymeleaf 一样，是服务器端页面渲染技术。这里我们不必关心 JSP 语法细节，编写一个超链接标签即可。

7、编译

此时直接执行 mvn compile 命令出错：

DANGER
程序包 javax.servlet.http 不存在

程序包 javax.servlet 不存在

找不到符号

符号: 类 HttpServlet

……

Copied!

上面的错误信息说明：我们的 Web 工程用到了 HttpServlet 这个类，而 HttpServlet 这个类属于 servlet-api.jar 这个 jar 包。此时我们说，Web 工程需要依赖 servlet-api.jar 包。

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

对于不知道详细信息的依赖可以到https://mvnrepository.com/网站查询。使用关键词搜索，然后在搜索结果列表中选择适合的使用。

比如，我们找到的 servlet-api 的依赖信息：

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

Copied!

这样就可以把上面的信息加入 pom.xml。重新执行 mvn compile 命令。

9、将 Web 工程打包为 war 包

运行 mvn package 命令，生成 war 包的位置如下图所示：

这个打包就会把所有的第三方依赖一起打进war包里，和普通工程就不一样了

10、将 war 包部署到 Tomcat 上运行

将 war 包复制到 Tomcat/webapps 目录下

启动 Tomcat：

通过浏览器尝试访问：http://localhost:8080/pro02-maven-web/index.jsp

二、依赖一个jar包

1、观念

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

2、操作

在 pro02-maven-web 工程的 pom.xml 中，找到 dependencies 标签，在 dependencies 标签中做如下配置：

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

Copied!

3、执行maven命令

①测试命令

mvn test

说明：测试操作中会提前自动执行编译操作，测试成功就说明编译也是成功的。

②打包命令

mvn package

通过查看 war 包内的结构，我们看到被 Web 工程依赖的 Java 工程确实是会变成 Web 工程的 WEB-INF/lib 目录下的 jar 包。

③查看当前 Web 工程所依赖的 jar 包的列表

mvn dependency:list

TIP

[INFO] The following files have been resolved: [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] junit:junit:jar:4.12:test

说明：javax.servlet:javax.servlet-api:jar:3.1.0:provided 格式显示的是一个 jar 包的坐标信息。格式是：

groupId:artifactId:打包方式:version:依赖的范围

这样的格式虽然和我们 XML 配置文件中坐标的格式不同，但是本质上还是坐标信息，大家需要能够认识这样的格式，将来从 Maven 命令的日志或错误信息中看到这样格式的信息，就能够识别出来这是坐标。进而根据坐标到Maven 仓库找到对应的jar包，用这样的方式解决我们遇到的报错的情况。

④以树形结构查看当前 Web 工程的依赖信息

mvn dependency:tree

TIP

[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

我们在 pom.xml 中并没有依赖 hamcrest-core，但是它却被加入了我们依赖的列表。原因是：junit 依赖了hamcrest-core，然后基于依赖的传递性，hamcrest-core 被传递到我们的工程了。

3 父子工程-命令行

Sun, 03 Mar 2024 15:49:51 +0800

一、创建父工程

创建的过程和前面创建普通工程一样。

工程名称：pro03-maven-parent

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

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

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

Copied!

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

二、创建模块工程

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

假设，我们创建三个模块工程：

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

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

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

Copied!

四、解读子工程的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> -->

Copied!

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

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

Copied!

六、子工程中引用那些被父工程管理的依赖

关键点：省略版本号

<!-- 把版本号去掉就表示子工程中这个依赖的版本由父工程决定。 -->
<!-- 具体来说是由父工程的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>

Copied!

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

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

Copied!

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

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

Copied!

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

八、实际意义

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

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

实验多重继承：

1、aaa项目：

		<groupId>org.example</groupId>
    <artifactId>aaa</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>pom</packaging>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.javassist</groupId>
                <artifactId>javassist</artifactId>
                <version>3.24.1-GA</version>
            </dependency>
            <dependency>
                <groupId>com.google.guava</groupId>
                <artifactId>guava</artifactId>
                <version>24.0-jre</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

Copied!

2、bbb项目继承aaa项目：

重新定义 javassist的版本

		<parent>
        <groupId>org.example</groupId>
        <artifactId>aaa</artifactId>
        <version>1.0-SNAPSHOT</version>
    </parent>
		<modelVersion>4.0.0</modelVersion>
    <artifactId>bbb</artifactId>
    <packaging>pom</packaging>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.javassist</groupId>
                <artifactId>javassist</artifactId>
                <version>3.28.0-GA</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

Copied!

3、ccc项目继承bbb项目：

		<parent>
        <groupId>org.example</groupId>
        <artifactId>bbb</artifactId>
        <version>1.0-SNAPSHOT</version>
    </parent>

    <modelVersion>4.0.0</modelVersion>
    <artifactId>ccc</artifactId>

    <dependencies>
        <dependency>
            <groupId>org.javassist</groupId>
            <artifactId>javassist</artifactId>
        </dependency>
        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
        </dependency>
    </dependencies>

Copied!

4、发现

这时执行 mvn dependency:tree 发现：

1、javassist的版本是bbb项目定义的版本，被覆盖了；

2、guava的版本还是aaa项目的版本；

3、并且当修改aaa项目的guava版本，aaa项目内 mvn install 后，在ccc项目中重新加载后，发现guava版本也随之更改，这时就跟bbb项目的状态无关。

tip:

在bbb项目虽然是pom的打包格式，但是也可以写dependencies，直接依赖jar包，和dependencyManagement分别做两件事，不会出错

4 springboot项目

Sun, 03 Mar 2024 16:49:51 +0800

一、模块划分

一个父工程，一个子工程微服务，一个普通maven子工程

二、建父工程

1、github建仓库

2、idea新建maven项目（父工程）

3、idea工程和github建立联系

选中 scr和pom.xml ，git add
git commit
git fetch
命令行输入：

1
2

git branch --set-upstream-to=origin/master
git merge origin/master --allow-unrelated-histories

Copied!

commit + push 推送远程仓库
接下来就可以直接开发了

三、建子工程

另一个子工程以同样方式创建

四、父子关系

三个工程的pom文件内容是这样的：

springboot-parent-child

<?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.example</groupId>
    <artifactId>springboot-parent-child</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>pom</packaging>

    <modules>
        <module>user-service</module>
        <module>base-entity</module>
    </modules>

    <properties>
      	<!-- maven-resources-plugin插件的默认取值 -->
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <!-- maven-site-plugin等插件的默认取值 -->
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
      
      	<!-- maven-compiler-plugin插件的默认取值 -->
      	<maven.compiler.source>1.8</maven.compiler.source>
    		<maven.compiler.target>1.8</maven.compiler.target>
      
      	<!-- spring-boot-starter-parent里定义的的默认取值 -->
        <java.version>1.8</java.version>
      
        <spring-boot-version>2.6.3</spring-boot-version>
    </properties>
<!-- 
<parent>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-parent</artifactId>
	<version>2.6.3</version>
</parent>
-->
    <dependencyManagement>
        <dependencies>
            <!-- SpringBoot 依赖导入 -->
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-dependencies</artifactId>
                <version>${spring-boot-version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>

            <!-- SpringCloud 依赖导入 -->
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>2021.0.1</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>

            <!-- SpringCloud Alibaba 依赖导入 -->
            <dependency>
                <groupId>com.alibaba.cloud</groupId>
                <artifactId>spring-cloud-alibaba-dependencies</artifactId>
                <version>2021.0.1.0</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

  	<!-- 
    1、这里显式指定插件版本，其实版本在springboot的pom中有，但这种引入方式会对插件不友好
 		2、maven打包时会出现找不到版本的警告，为了规避，所以在这里指定版本，
						后面继承的子工程就可以直接依赖这个插件了
		3、用spring-boot-starter-parent引入的，插件可以直接使用，没有警告			
		-->
    <!-- build 标签：用来配置对构建过程的定制 -->
    <build>
        <pluginManagement>
            <!-- plugins 标签：定制化构建过程中所使用到的插件 -->
            <plugins>
                <!-- plugin 标签：一个具体插件 -->
                <plugin>
                    <groupId>org.springframework.boot</groupId>
                    <artifactId>spring-boot-maven-plugin</artifactId>
                    <version>${spring-boot-version}</version>
                </plugin>
            </plugins>
        </pluginManagement>
    </build>
</project>

Copied!

user-service

<?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">
    <parent>
        <artifactId>springboot-parent-child</artifactId>
        <groupId>org.example</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>
    <artifactId>user-service</artifactId>

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

        <dependency>
            <groupId>org.example</groupId>
            <artifactId>base-entity</artifactId>
            <version>1.0-SNAPSHOT</version>
        </dependency>

    </dependencies>

    <!-- build 标签：用来配置对构建过程的定制 -->
    <build>
        <!-- plugins 标签：定制化构建过程中所使用到的插件 -->
        <plugins>
            <!-- plugin 标签：一个具体插件 -->
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
              <!-- 
							1、对于用import引入的springboot，这里要指定这个目标，否则执行mvn package时，不会自动执行springboot:repackage
							2、如果不这样指定的话，那打包命令需要显式指定插件，命令为：
							mvn clean package spring-boot:repackage -Dmaven.test.skip=true
							3、repackage前面必须有已经存在的包，否则会出错，所以前面跟着一个package原生命令
 							-->
                <executions>
                    <execution>
                        <goals>
                            <goal>repackage</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

</project>

Copied!

base-entity

<?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">
    <parent>
        <artifactId>springboot-parent-child</artifactId>
        <groupId>org.example</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>
    <artifactId>base-entity</artifactId>

    <dependencies>
        <!-- OpenFeign 专用依赖 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-openfeign</artifactId>
        </dependency>

        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <scope>provided</scope>
        </dependency>
    </dependencies>

</project>

Copied!

部署

`1`	`nohup java -jar user-service-1.0-SNAPSHOT.jar>demo06.log 2>&1 &`

Copied!

注意

1、引入springboot的方式

不是每个人都喜欢从 spring-boot-starter-parent 继承 POM。您可能需要使用自己公司标准的父 POM，或者您可能只是希望明确地声明所有 Maven 配置。
如果您不想使用 spring-boot-starter-parent，则仍然可以通过使用 scope=import 依赖来获得依赖管理（但不是插件管理）的好处：
假如 A工程这样配置，这种方式只能在后面继承这个A工程的的子工程中去覆盖依赖的版本：

<packaging>pom</packaging>
...
...
<dependencyManagement>
        <dependencies>
            <!-- SpringBoot 依赖导入 -->
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-dependencies</artifactId>
                <version>2.6.3</version>
                <type>pom</type>
                <scope>import</scope>
           </dependency>
        </dependencies>
</dependencyManagement>

Copied!

如果这样，是覆盖不了的：

<packaging>pom</packaging>
...
...
<dependencyManagement>
        <dependencies>
            <!-- SpringBoot 依赖导入 -->
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-dependencies</artifactId>
                <version>2.6.3</version>
                <type>pom</type>
                <scope>import</scope>
           </dependency>
        </dependencies>
</dependencyManagement>

<dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <version>2.6.4</version>
        </dependency>
</dependencies>

Copied!

但是这样，可以覆盖某个依赖的版本：

<packaging>pom</packaging>
...
...
<dependencyManagement>
        <dependencies>
            <!-- SpringBoot 依赖导入 -->
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-dependencies</artifactId>
                <version>2.6.3</version>
                <type>pom</type>
                <scope>import</scope>
           </dependency>
          
          <!-- 覆盖web的版本 -->
          <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-web</artifactId>
                <version>2.6.4</version>
          </dependency>
          
        </dependencies>
</dependencyManagement>

Copied!

这种方式引入，也会使spring-boot-maven-plugin 引入进来，但是打包时有warning

5 build标签和插件

Sun, 03 Mar 2024 17:49:51 +0800

一、插件和目标

1、插件

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

2、目标

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

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

3、调用插件的方法

方式一：通过生命周期映射的方式，将插件的goal绑定到生命周期中的phase上，然后调用phase。例如：maven-jar-plugin插件提供了一个叫jar的goal，默认会绑定到生命周期的package阶段(phase)。调用mvn package就会自动调用maven-jar-plugin:jar。生命周期中所有前置的phase会先自动执行。

`1`	`package <==> maven-jar-plugin:jar`

Copied!

方式二：直接调用插件的某个功能(goal)。如mvn maven-jar-plugin:jar。maven有一个约定，如果插件的名字叫maven-xxxx-plugin或xxxx-maven-plugin的话。可以直接用mvn xxxx:goal的方式调用其提供的功能。所以前面这个命令就可以简写成：mvn jar:jar。这种方式只会执行指定的goal。

调用goal完整的命令格式为：

1
2

　　mvn <plugin-prefix>:<goal>
　　mvn [<plugin-group-id>:]<plugin-artifact-id>[:<plugin-version>]:<goal>

Copied!

可以通过命令查看插件的详细信息：

`1`	`mvn help:describe -Dplugin=org.apache.maven.plugins:maven-compile-plugin –Ddetail`

Copied!

二、build标签

1、介绍

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

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

2、build标签组成

①、定义约定的目录结构

参考示例中的如下部分：

<sourceDirectory>D:\idea2019workspace\atguigu-maven-test-prepare\src\main\java</sourceDirectory>
<scriptSourceDirectory>D:\idea2019workspace\atguigu-maven-test-prepare\src\main\scripts</scriptSourceDirectory>
<testSourceDirectory>D:\idea2019workspace\atguigu-maven-test-prepare\src\test\java</testSourceDirectory>
<outputDirectory>D:\idea2019workspace\atguigu-maven-test-prepare\target\classes</outputDirectory>
<testOutputDirectory>D:\idea2019workspace\atguigu-maven-test-prepare\target\test-classes</testOutputDirectory>
<resources>
    <resource>
        <directory>D:\idea2019workspace\atguigu-maven-test-prepare\src\main\resources</directory>
    </resource>
</resources>
<testResources>
    <testResource>
        <directory>D:\idea2019workspace\atguigu-maven-test-prepare\src\test\resources</directory>
    </testResource>
</testResources>
<directory>D:\idea2019workspace\atguigu-maven-test-prepare\target</directory>

Copied!

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

目录名	作用
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 管理的插件信息：

<pluginManagement>
      <plugins>
          <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <version>2.6.2</version>
          </plugin>
  		</plugins>
</pluginManagement>

Copied!

子工程使用的插件信息：

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

Copied!

③、插件结构

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

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

Copied!

[1] 坐标部分

artifactId 和 version 标签定义了插件的坐标，作为 Maven 的自带插件这里省略了 groupId。

[2] 执行部分

executions 标签内可以配置多个 execution 标签，execution 标签内：

id：指定唯一标识
phase：关联的生命周期阶段
goals/goal：关联指定生命周期的目标
- goals 标签中可以配置多个 goal 标签，表示一个生命周期环节可以对应当前插件的多个目标。

另外，插件目标的执行过程可以进行配置，例如 maven-site-plugin 插件的 site 目标：

<execution>
    <id>default-site</id>
    <phase>site</phase>
    <goals>
        <goal>site</goal>
    </goals>
    <configuration>
        <outputDirectory>D:\idea2019workspace\atguigu-maven-test-prepare\target\site</outputDirectory>
        <reportPlugins>
            <reportPlugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-project-info-reports-plugin</artifactId>
            </reportPlugin>
        </reportPlugins>
    </configuration>
</execution>

Copied!

configuration 标签内进行配置时使用的标签是插件本身定义的。就以 maven-site-plugin 插件为例，它的核心类是 org.apache.maven.plugins.site.render.SiteMojo，在这个类中我们看到了 outputDirectory 属性：

SiteMojo 的父类是：AbstractSiteRenderingMojo，在父类中我们看到 reportPlugins 属性：

结论：每个插件能够做哪些设置都是各个插件自己规定的，无法一概而论。

三、定义jdk版本和编码

1、直接使用默认取值

<properties>
      	<!-- maven-resources-plugin和maven-compiler-plugin插件的默认取值 -->
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  
  			<!-- maven-site-plugin等插件的默认取值 -->
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
      
      	<!-- maven-compiler-plugin插件的默认取值 -->
      	<maven.compiler.source>1.8</maven.compiler.source>
    		<maven.compiler.target>1.8</maven.compiler.target>
      
      	<!-- spring-boot-starter-parent里定义的的默认取值 -->
        <java.version>1.8</java.version>
      
</properties>

Copied!

2、或者在插件中定义

<project>
  [...]
  <!-- build 标签：意思是告诉 Maven，你的构建行为，我要开始定制了！ -->
  <build>
    [...]
    <!-- plugins 标签：Maven 你给我听好了，你给我构建的时候要用到这些插件！ -->
    <plugins>
      
      <!-- JDK版本 -->
      <plugin>
        <!-- 插件的坐标。此处引用的 maven-compiler-plugin 插件不是第三方的，是一个 Maven 自带的插件。 -->
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.10.1</version>
        <!-- configuration 标签：配置 maven-compiler-plugin 插件 -->
        <configuration>
          <!-- 具体配置信息会因为插件不同、需求不同而有所差异 -->
          <source>1.8</source>
          <target>1.8</target>
          <encoding>UTF-8</encoding>
        </configuration>
      </plugin>
    
    	<!-- 编码 -->
   		<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-resources-plugin</artifactId>
        <version>3.2.0</version>
        <configuration>
          ...
          <encoding>UTF-8</encoding>
          ...
        </configuration>
      </plugin>
      
      
      
    </plugins>
    [...]
  </build>
  [...]
</project>

Copied!

source 标签含义

翻译过来就是：调用 Java 编译器命令时传入的 -source 参数。那对编译器来说，-source 参数是啥意思呢？

『提供与指定发行版的源兼容性』这句话我的理解是：

我们写代码是按 JDK 1.8 写的——这就是『源兼容性』里的『源』。
指定发行版就是我们指定的 JDK 1.8。
『兼容性』是谁和谁兼容呢？现在源代码是既定的，所以就是要求编译器使用指定的 JDK 版本来兼容我们的源代码。

target 标签含义

调用 Java 编译器命令时传入的 -target 参数

『生成特定 VM 版本的类文件』这句话我的理解是：

VM 指 JVM
类文件指 *.class 字节码文件
整体意思就是源文件编译后，生成的 *.class 字节码文件要符合指定的 JVM 版本

3、或写在超级pom里，全局设定

配置的方式是：将 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>

Copied!

不推荐,仅在本地生效，如果脱离当前的settings.xml能够覆盖的范围，则无法生效

四、help 插件的各个目标

官网说明地址：https://maven.apache.org/plugins/maven-help-plugin

目标	说明
help:active-profiles	列出当前已激活的 profile
help:all-profiles	列出当前工程所有可用 profile
help:describe	描述一个插件和/或 Mojo 的属性
help:effective-pom	以 XML 格式展示有效 POM
help:effective-settings	为当前工程以 XML 格式展示计算得到的 settings 配置
help:evaluate	计算用户在交互模式下给出的 Maven 表达式
help:system	显示平台详细信息列表，如系统属性和环境变量

五、springboot打包插件

1、打包

<build>
	<plugins>
		<plugin>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-maven-plugin</artifactId>
			<version>2.5.5</version>
		</plugin>
	</plugins>
</build>

Copied!

很显然 spring-boot-maven-plugin 并不是 Maven 自带的插件，而是 SpringBoot 提供的，用来改变 Maven 默认的构建行为。具体来说是改变打包的行为。默认情况下 Maven 调用 maven-jar-plugin 插件的 jar 目标，生成普通的 jar 包。

普通 jar 包没法使用 java -jar xxx.jar 这样的命令来启动、运行，但是 SpringBoot 的设计理念就是每一个『微服务』导出为一个 jar 包，这个 jar 包可以使用 java -jar xxx.jar 这样的命令直接启动运行。

这样一来，打包的方式肯定要进行调整。所以 SpringBoot 提供了 spring-boot-maven-plugin 这个插件来定制打包行为。

2、插件的七个目标

目标名称	作用
spring-boot:build-image	Package an application into a OCI image using a buildpack.
spring-boot:build-info	Generate a build-info.properties file based on the content of the current MavenProject.
spring-boot:help	Display help information on spring-boot-maven-plugin. Call mvn spring-boot:help -Ddetail=true -Dgoal= to display parameter details.
spring-boot:repackage	Repackage existing JAR and WAR archives so that they can be executed from the command line using java -jar. With layout=NONE can also be used simply to package a JAR with nested dependencies (and no main class, so not executable).
spring-boot:run	Run an application in place.
spring-boot:start	Start a spring application. Contrary to the run goal, this does not block and allows other goals to operate on the application. This goal is typically used in integration test scenario where the application is started before a test suite and stopped after.
spring-boot:stop	Stop an application that has been started by the ‘start’ goal. Typically invoked once a test suite has completed.

六、自定义插件

1、创建工程

创建一个常规的maven工程
然后修改打包方式：
1

<packaging>maven-plugin</packaging>
Copied!

引入依赖（二选一）：

[1] 将来在文档注释中使用注解

<dependency>
    <groupId>org.apache.maven</groupId>
    <artifactId>maven-plugin-api</artifactId>
    <version>3.5.2</version>
</dependency>

Copied!

[2] 将来直接使用注解

<dependency>
    <groupId>org.apache.maven.plugin-tools</groupId>
    <artifactId>maven-plugin-annotations</artifactId>
    <version>3.5.2</version>
</dependency>

Copied!

创建 Mojo 类

Mojo 类是一个 Maven 插件的核心类。

Mojo 这个单词的意思是：Maven Old Java Object，其实 mojo 这个单词本身包含魔力;符咒(袋);护身符;(人的)魅力的含义，Maven 用 Mojo 是因为它是对 POJO 开的一个小玩笑。

[1] Mojo 接口

每一个 Mojo 都需要实现 org.apache.maven.plugin.Mojo 接口

**[2] AbstractMojo 抽象

我们实现 Mojo 接口比较困难，幸好可以继承 AbstractMojo，此时我们只要实现 execute() 这一个方法即可。

public class MyHelloPlugin extends AbstractMojo {
    @Override
    public void execute() throws MojoExecutionException, MojoFailureException {
        getLog().info("---> This is my first maven plugin. <---");
    }
}

Copied!

2、插件配置

①、Mojo 类中的配置

[1]文档注释中用注解

对应的 pom.xml 中的依赖： maven-plugin-api

[2]直接在类上标记注解

对应 pom.xml 中的依赖：maven-plugin-annotations

// name 属性：指定目标名称
@Mojo(name = "firstBlood")
public class MyPluginOfFistBlood extends AbstractMojo {
    @Override
    public void execute() throws MojoExecutionException, MojoFailureException {
        getLog().info("---> first blood <---");
    }
}

Copied!

②、安装插件

要在后续使用插件，就必须至少将插件安装到本地仓库。 mvn install

③、注册插件

我们需要将插件坐标中的 groupId 部分注册到 settings.xml 中。

<pluginGroups>
	<!-- pluginGroup
	 | Specifies a further group identifier to use for plugin lookup.
	<pluginGroup>com.your.plugins</pluginGroup>
	-->
	<pluginGroup>com.atguigu.maven</pluginGroup>
</pluginGroups>

Copied!

3、使用插件

①、识别插件前缀

Maven 根据插件的 artifactId 来识别插件前缀。例如下面两种情况：

[1]前置匹配

匹配规则：${prefix}-maven-plugin
artifactId：hello-maven-plugin
前缀：hello

[2]中间匹配

匹配规则：maven-${prefix}-plugin
artifactId：maven-good-plugin
前缀：good

②在命令行直接用

命令：

`1`	`mvn hello:sayHello`

Copied!

效果：

③、配置到 build 标签里用

<build>
	<plugins>
		<plugin>
			<groupId>com.atguigu.maven</groupId>
			<artifactId>hello-maven-plugin</artifactId>
			<version>1.0-SNAPSHOT</version>
			<executions>
				<execution>
                    <id>hello</id>
                    <!-- 指定和目标关联的生命周期阶段 -->
					<phase>clean</phase>
					<goals>
						<goal>sayHello</goal>
					</goals>
				</execution>
                <execution>
                    <id>blood</id>
                    <phase>validate</phase>
                    <goals>
                        <goal>firstBlood</goal>
                    </goals>
                </execution>
			</executions>
		</plugin>
	</plugins>
</build>

Copied!

执行已和插件目标绑定的生命周期：

七、maven常用插件

1、maven-compiler-plugin

默认绑定到comile phase。用于编译项目源代码。 compile目标会编译src/main/java目录下的源代码。 testCompile目标会编译src/test/java目录下的测试代码。

maven compile编译源代码。 maven testCompile编译源代码+测试代码。

配置：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.6.0</version>
    <configuration>
        <source>1.8</source> <!-- 源代码使用jdk1.8支持的特性 -->
        <target>1.8</target> <!-- 使用jvm1.8编译目标代码 -->
      	<encoding>utf-8</encoding> <!-- 编码 -->
      	<skipTests>true</skipTests>  <!-- 是否跳过测试 -->
  			<showWarnings>true</showWarnings>
      	<meminitial>128m</meminitial> <!-- 编译器使用的初始内存 -->
      	<maxmem>512m</maxmem>  <!-- 编译器使用的最大内存 -->
      	<compilerArgs> <!-- 传递参数 --> 
          <compilerArgs> <!-- 传递参数 -->
                        <arg>-Xlint:unchecked</arg><!--启用对未经检查的转换的警告   Map map = new HashMap();
                                                         map.put("a", new A());-->
                        <arg>-Xlint:deprecation</arg><!--显示关于使用了过时的 API 的详细信息-->
        </compilerArgs>
    </configuration>
</plugin>

Copied!

用户可以通过两种方式调用Maven插件目标。

第一种方式是将插件目标与生命周期阶段（lifecycle phase）绑定，这样用户在命令行只是输入生命周期阶段而已，例如Maven默认将maven-compiler-plugin的compile目标与compile生命周期阶段绑定，因此命令mvn compile实际上是先定位到compile这一生命周期阶段，然后再根据绑定关系调用maven-compiler-plugin的compile目标。

第二种方式是直接在命令行指定要执行的插件目标，例如mvn archetype:generate 就表示调用maven-archetype-plugin的generate目标，这种带冒号的调用方式与生命周期无关。

2、maven-resources-plugin

①、分环境配置

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-resources-plugin</artifactId>
    <version>2.5</version>
    <configuration>
        <resources>
            <resource>
                <directory>src/main/resources</directory>
                <!-- 先把所有环境的配置全部排除 -->
                <excludes>
                    <exclude>dev/**</exclude>
                    <exclude>prod/**</exclude>
                </excludes>
            </resource>
            <resource>
                <directory>src/main/resources/${active.profile}</directory>
                <!-- 再把当前环境的配置引入 -->
                <includes>
                    <include>**/*.xml</include>
                    <include>**/*.properties</include>
                </includes>
            </resource>
        </resources>
    </configuration>
</plugin>
<!-- 或者 -->
<build>
    <resources>
        <resource>
            <directory>src/main/resources</directory>
            <!-- 先把所有环境的配置全部排除 -->
            <excludes>
                <exclude>dev/**</exclude>
                <exclude>prod/**</exclude>
            </excludes>
        </resource>
        <resource>
            <directory>src/main/resources/${active.profile}</directory>
            <!-- 再把当前环境的配置引入 -->
            <includes>
                <include>**/*.xml</include>
                <include>**/*.properties</include>
            </includes>
        </resource>
    </resources>
</build>

Copied!

配置profile

<profiles>
    <profile>
        <id>dev</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <properties>
            <active.profile>dev</active.profile>
        </properties>
    </profile>
    <profile>
        <id>prod</id>
        <properties>
            <active.profile>prod</active.profile>
        </properties>
    </profile>
</profiles>

Copied!

②、打源码包

<build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-source-plugin</artifactId>
                <version>3.0.1</version>
                <executions>
                    <execution>
                        <id>attach-sources</id>
                        <phase>verify</phase>
                        <goals>
                            <goal>jar-no-fork</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
</build>

Copied!

3、maven-surefire-plugin

用于跑测试用例

此插件可以不在pom.xml里面声明，maven运行命令时，会自动调用该插件。一些有用的配置：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
      	<testFailureIgnore>true</testFailureIgnore>  <!--测试有失败用例时，是否继续构建-->
      	<skipTests>true</skipTests>                  <!--是否跳过测试阶段，方式1-->
　　　   <skip>true</skip>                            <!--是否跳过测试阶段，方式2-->
        <skipAfterFailureCount>1</skipAfterFailureCount>  <!-- 只要有一个用例测试失败，就立即停止。默认情况下会跑完所有测试用例 -->
        <rerunFailingTestsCount>2</rerunFailingTestsCount>  <!-- 失败重试次数 -->
        <parallel>methods</parallel>  <!-- 并发执行测试用例 -->
        <threadCount>10</threadCount>  <!-- 并发执行时的线程数量 -->
    </configuration>
</plugin>

Copied!

4、spring-boot-maven-plugin

spring-boot开发必备插件。它能将spring-boot项目代码及其依赖jar打包成一个完整的可执行的jar包（fat jar）作用和插件maven-shade-plugin差不多。 repackage的goal绑定在生命周期的package阶段。使用方式：

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <executions>
        <execution>
            <goals>
                <goal>repackage</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Copied!

如果指定了spring-boot作为parent，可以不指定版本和repackage goal：

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>1.3.8.RELEASE</version>
    <configuration>
        <mainClass>${start-class}</mainClass>
   </configuration>
</parent>

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
</plugin>

Copied!

spring-boot查找main文件的流程是：

1、首先查看<mainClass>是否有值，如果有，直接拿标签内的类名作为入口。

1
2
3

<properties>
    <start-class>com.example.Application</start-class>
</properties>

Copied!

2、如果没找到<start-class>标签，会遍历所有文件，找到注解了@SpringBootApplication并含有main方法的类，将其作为入口。实践证明，如果没有定义<start-class>，查找入口类的方法也是非常快的。在实际开发中，推荐手动定义<start-class>。这样在一个项目工程中可以有多个@SpringBootApplication注解的类，修改一下pom里的配置就能灵活切换入口了。

5、maven-jar-plugin

这个是普通java项目（非java web项目和其他特殊类型的java项目）package阶段默认绑定的插件，能够将编译好的class和资源打成jar包。

常用配置：打出可以运行的有主类的jar包

<plugin>  
    <groupId>org.apache.maven.plugins</groupId>  
    <artifactId>maven-jar-plugin</artifactId>
    <version>3.0.2</version>
    <configuration>  
        <archive>  
          	<!--加描述-->
            <addMavenDescriptor>false</addMavenDescriptor>  
            <manifest>  
              	<!--是否要把第三方jar放到manifest的classpath中-->
                <addClasspath>true</addClasspath>  
              	<!--生成的manifest中classpath的前缀，因为要把第三方jar放到lib目录下，不是代码里的目录-->
                <classpathPrefix>lib/</classpathPrefix>  
              <!-- 执行的主程序路径 -->
                <mainClass>com.meix.boot.Application</mainClass>  
            </manifest>
        </archive>  
         <!-- 过滤掉不希望包含在jar中的文件  -->  
        <excludes>  
            <exclude>*.xml</exclude>  
            <exclude>spring/**</exclude>  
            <exclude>config/**</exclude>  
        </excludes> 
        <!-- 把配置的这个目录下的部分资源打包，其他目录的java类不打 -->
        <includes>
            <include>**/api/*</include>
        </includes>         
    </configuration>  
</plugin>

Copied!

把maven依赖的jar复制到lib目录下

<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-dependency-plugin</artifactId>
			<version>2.10</version>
			<executions>
				<execution>
					<id>copy-dependencies</id>
					<phase>package</phase>
					<goals>
						<goal>copy-dependencies</goal>
					</goals>
					<configuration>
						<outputDirectory>${project.build.directory}/lib</outputDirectory>
					</configuration>
				</execution>
			</executions>
</plugin>

Copied!

打开 MENIFEST.MF 文件可以看到如下内容：

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Built-By: sandy
//表示依赖的第三方jar包在哪里，显然需要放在和 当前jar包同级目录下的 lib文件夹下
Class-Path: lib/gson-2.8.5.jar lib/guava-19.0.jar lib/slf4j-api-1.7.25
 .jar lib/logback-core-1.2.3.jar lib/logback-access-1.2.3.jar lib/logb
 ack-classic-1.2.3.jar lib/lombok-1.18.2.jar lib/commons-lang3-3.8.1.j
 ar lib/commons-io-2.2.jar     
Created-By: Apache Maven 3.5.2
Build-Jdk: 1.8.0_121
Main-Class: com.example.demo.test.App  //表示运行的主程序

Copied!

所以安装包的路径结构应该是：

为此需要通过 maven-assembly-plugin 插件来组装出安装包。

针对本示例对应的 maven-assembly-plugin 配置如下：

<plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-assembly-plugin</artifactId>
      <executions>
        <execution>
          <id>make-assembly</id>
          <phase>package</phase>
          <goals>
            <goal>single</goal>
          </goals>
        </execution>
      </executions>
      <configuration>
        <descriptors>  
          <!-- 和 pom.xml 同级目录下 -->
          <descriptor>assembly.xml</descriptor>
        </descriptors>
        <!-- assembly 组装出来的包会被放置在和 pom.xml同级目录下的output目录下 -->
        <outputDirectory>output</outputDirectory>
        <!-- true：会在生成的zip包名后面加上 id-->
        <appendAssemblyId>false</appendAssemblyId>
      </configuration>
</plugin>

Copied!

assembly.xml 内容如下：

<?xml version='1.0' encoding='UTF-8'?>
<assembly xmlns="http://maven.apache.org/ASSEMBLY/2.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.1.0 http://maven.apache.org/xsd/assembly-2.1.0.xsd">
    <id>test-maven</id>
    <formats>
        <format>zip</format>
    </formats>
    <includeBaseDirectory>false</includeBaseDirectory>
    <fileSets>
        <fileSet>
            <!-- ${project.build.directory} 指 target目录 -->
            <directory>${project.build.directory}</directory>
            <!-- 表示输出到 pom 中配置的 output目录下 -->
            <outputDirectory>/</outputDirectory>
            <includes>
                <!-- 把jar放入zip包根目录 -->
                <include>test-maven*.jar</include>
                <!-- dependency插件复制的依赖jar放入zip -->
                <include>lib/*</include>
            </includes>
        </fileSet>
        <fileSet>
            <directory>${project.build.directory}/classes</directory>
            <!-- 表示输出到 pom 中配置的 output/config 目录下 -->
            <outputDirectory>/config</outputDirectory>
            <includes>
                <include>application.properties</include>
            </includes>
        </fileSet>
        <fileSet>
            <!-- ${project.basedir} 指 工程根目录 -->
            <directory>${project.basedir}</directory>
            <outputDirectory>/</outputDirectory>
            <includes>
                <include>doc/*.*</include>
            </includes>
        </fileSet>
    </fileSets>
</assembly>

Copied!

要自定义 jar 包名称，可以直接在 pom.xml 中 build 结点下设置 finalName，如：

1
2
3

<build>
      <finalName>p-test-tool</finalName>
</build>

Copied!

6、maven-assembly-plugin

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-assembly-plugin</artifactId>
                <executions>
                    <execution>
                        <id>make-assembly</id>
                        <phase>package</phase>
                        <goals>
                            <goal>single</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <descriptorRefs>
                        <!-- 使用官方的打包策略 -->
                        <descriptorRef>jar-with-dependencies</descriptorRef>
                    </descriptorRefs>
                    <archive>
                        <manifest>
                            <mainClass>a.App</mainClass>
                        </manifest>
                    </archive>
                    <!-- assembly 组装出来的包会被放置在和 pom.xml同级目录下的output目录下 -->
                    <outputDirectory>output</outputDirectory>
                    <!-- true：会在生成的zip包名后面加上 id-->
                    <appendAssemblyId>false</appendAssemblyId>
                </configuration>
            </plugin>
        </plugins>
    </build>

Copied!

7、maven-shade-plugin

<build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-shade-plugin</artifactId>
        <version>3.3.0</version>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>shade</goal>
            </goals>
            <configuration>
              <transformers>
                <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                  <mainClass>org.sonatype.haven.HavenCli</mainClass>
                </transformer>
              </transformers>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

Copied!

6 生产实践

Sun, 03 Mar 2024 18:49:51 +0800

一、jar包冲突问题

1、谁需要面对 jar 包冲突？

先给结论：编订依赖列表的程序员。初次设定一组依赖，因为尚未经过验证，所以确实有可能存在各种问题，需要做有针对性的调整。那么谁来做这件事呢？我们最不希望看到的就是：团队中每个程序员都需要自己去找依赖，即使是做同一个项目，每个模块也各加各的依赖，没有统一管理。那前人踩过的坑，后人还要再踩一遍。而且大家用的依赖有很多细节都不一样，版本更是五花八门，这就让事情变得更加复杂。

所以虽然初期需要根据项目开发和实际运行情况对依赖配置不断调整，最终确定一个各方面都 OK 的版本。但是一旦确定下来，放在父工程中做依赖管理，各个子模块各取所需，这样基本上就能很好的避免问题的扩散。

即使开发中遇到了新问题，也可以回到源头检查、调整 dependencyManagement 配置的列表——而不是每个模块都要改。所以学完这一节你应该就会对前面讲过的『继承』有了更深的理解。

2、表现形式

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

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

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

①抛异常：找不到类

此时抛出的常见的异常类型：

java.lang.ClassNotFoundException：编译过程中找不到类
java.lang.NoClassDefFoundError：运行过程中找不到类
java.lang.LinkageError：不同类加载器分别加载的多个类有相同的全限定名

我们来举个例子：

<dependency>
    <groupId>org.apache.httpcomponents</groupId>
    <artifactId>httpclient</artifactId>
    <version>4.x.x</version>
</dependency>

Copied!

httpclient 这个 jar 包中有一个类：org.apache.http.conn.ssl.NoopHostnameVerifier。这个类在较低版本中没有，但在较高版本存在。比如：

jar 包版本	是否存在
4.3.6	否
4.4	是

那当我们确实需要用到 NoopHostnameVerifier 这个类，我们看到 Maven 通过依赖传递机制引入了这个 jar 包，所以没有明确地显式声明对这个 jar 包的依赖。可是 Maven 传递过来的 jar 包是 4.3.6 版本，里面没有包含我们需要的类，就会抛出异常。

而『冲突』体现在：4.3.6 和 4.4 这两个版本的 jar 包都被框架所依赖的 jar 包给传递进来了，但是假设 Maven 根据**『版本仲裁』**规则实际采纳的是 4.3.6。

②抛异常：找不到方法

程序找不到符合预期的方法。这种情况多见于通过反射调用方法，所以经常会导致：java.lang.NoSuchMethodError。比如 antlr:antlr:x.x.x 这个包中有一个接口：antlr.collections.AST

版本	getLine()方法
2.7.2	无
2.7.6	有

③没报错但结果不对

发生这种情况比较典型的原因是：两个 jar 包中的类分别实现了同一个接口，这本来是很正常的。但是问题在于：由于没有注意命名规范，两个不同实现类恰巧是同一个名字。

具体例子是有的同学在实际工作中遇到过：项目中部分模块使用 log4j 打印日志；其它模块使用 logback，编译运行都不会冲突，但是会引起日志服务降级，让你的 log 配置文件失效。比如：你指定了 error 级别输出，但是冲突就会导致 info、debug 都在输出。

3、本质

以上表现形式归根到底是两种基本情况导致的：

①同一jar包的不同版本

②不同jar包中包含同名类

这里我们拿 netty 来举个例子，netty 是一个类似 Tomcat 的 Servlet 容器。通常我们不会直接依赖它，所以基本上都是框架传递进来的。那么当我们用到的框架很多时，就会有不同的框架用不同的坐标导入 netty。大家可以参照下表对比一下两组坐标：

截止到3.2.10.Final版本以前的坐标形式：	从3.3.0.Final版本开始以后的坐标形式：
org.jboss.netty netty 3.2.10.Final	io.netty netty 3.9.2.Final

但是偏偏这两个**『不同的包』里面又有很多『全限定名相同』**的类。例如：

org.jboss.netty.channel.socket.ServerSocketChannelConfig.class org.jboss.netty.channel.socket.nio.NioSocketChannelConfig.class org.jboss.netty.util.internal.jzlib.Deflate.class org.jboss.netty.handler.codec.serialization.ObjectDecoder.class org.jboss.netty.util.internal.ConcurrentHashMap$HashIterator.class org.jboss.netty.util.internal.jzlib.Tree.class org.jboss.netty.util.internal.ConcurrentIdentityWeakKeyHashMap$Segment.class org.jboss.netty.handler.logging.LoggingHandler.class org.jboss.netty.channel.ChannelHandlerLifeCycleException.class org.jboss.netty.util.internal.ConcurrentIdentityHashMap$ValueIterator.class org.jboss.netty.util.internal.ConcurrentIdentityWeakKeyHashMap$Values.class org.jboss.netty.util.internal.UnterminatableExecutor.class org.jboss.netty.handler.codec.compression.ZlibDecoder.class org.jboss.netty.handler.codec.rtsp.RtspHeaders$Values.class org.jboss.netty.handler.codec.replay.ReplayError.class org.jboss.netty.buffer.HeapChannelBufferFactory.class

……

其实还有很多，这里列出的只是冰山一角。

当然，如果全限定名相同，类中的代码也完全相同，那么用着也行。问题是如果**『全限定名相同』，但是『代码不同』**，那可太坑了。我们随便找一个来看看：

坐标信息：org.jboss.netty:netty:jar:3.2.10.Final
代码截图：

坐标信息：io.netty:netty:jar:3.9.2.Final
代码截图：

4、解决办法

①概述

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

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

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

②IDEA 的 Maven Helper 插件

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

基于 pom.xml 的依赖冲突分析

③Maven 的 enforcer 插件

使用 Maven 的 enforcer 插件既可以检测同一个 jar 包的不同版本，又可以检测不同 jar 包中同名的类。

引入 netty 依赖

这里我们引入两个对 netty 的依赖，展示不同 jar 包中有同名类的情况。

<dependencies>
    <dependency>
        <groupId>org.jboss.netty</groupId>
        <artifactId>netty</artifactId>
        <version>3.2.10.Final</version>
    </dependency>

    <dependency>
        <groupId>io.netty</groupId>
        <artifactId>netty</artifactId>
        <version>3.9.2.Final</version>
    </dependency>
</dependencies>

Copied!

配置 enforcer 插件

<build>
    <pluginManagement>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-enforcer-plugin</artifactId>
                <version>1.4.1</version>
                <executions>
                    <execution>
                        <id>enforce-dependencies</id>
                        <phase>validate</phase>
                        <goals>
                            <goal>display-info</goal>
                            <goal>enforce</goal>
                        </goals>
                    </execution>
                </executions>
                <dependencies>
                    <dependency>
                        <groupId>org.codehaus.mojo</groupId>
                        <artifactId>extra-enforcer-rules</artifactId>
                        <version>1.0-beta-4</version>
                    </dependency>
                </dependencies>
                <configuration>
                    <rules>
                        <banDuplicateClasses>
                            <findAllDuplicates>true</findAllDuplicates>
                        </banDuplicateClasses>
                    </rules>
                </configuration>
            </plugin>
        </plugins>
    </pluginManagement>
</build>

Copied!

测试

执行如下 Maven 命令：

`1`	`mvn clean package enforcer:enforce`

Copied!

部分运行结果：

[INFO] — maven-enforcer-plugin:1.4.1:enforce (default-cli) @ pro32-duplicate-class — [WARNING] Rule 0: org.apache.maven.plugins.enforcer.BanDuplicateClasses failed with message: Duplicate classes found:

Found in: io.netty:netty:jar:3.9.2.Final:compile org.jboss.netty:netty:jar:3.2.10.Final:compile Duplicate classes: org/jboss/netty/channel/socket/ServerSocketChannelConfig.class org/jboss/netty/channel/socket/nio/NioSocketChannelConfig.class org/jboss/netty/util/internal/jzlib/Deflate.class org/jboss/netty/handler/codec/serialization/ObjectDecoder.class org/jboss/netty/util/internal/ConcurrentHashMap$HashIterator.class

……

二、体系外jar包导入

1、提出问题

目前来说我们在 Maven 工程中用到的 jar 包都是通过 Maven 本身的机制导入进来的。

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

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

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

2、解决办法

①准备一个体系外 jar 包

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

②将该 jar 包安装到 Maven 仓库

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

mvn install:install-file -Dfile=[体系外 jar 包路径] \
-DgroupId=[给体系外 jar 包强行设定坐标] \
-DartifactId=[给体系外 jar 包强行设定坐标] \
-Dversion=1 \
-Dpackage=jar

Copied!

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

mvn install:install-file -Dfile=D:\idea2019workspace\atguigu-maven-outer\out\artifacts\atguigu_maven_outer\atguigu-maven-outer.jar ^
-DgroupId=com.atguigu.maven ^
-DartifactId=atguigu-maven-outer ^
-Dversion=1 ^
-Dpackaging=jar

Copied!

执行结果：

再看本地仓库中确实有：

我们打开 POM 文件看看：

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.atguigu.maven</groupId>
  <artifactId>atguigu-maven-outer</artifactId>
  <version>1</version>
  <description>POM was created from install:install-file</description>
</project>

Copied!

③测试

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

<dependency>
    <groupId>com.atguigu.maven</groupId>
    <artifactId>atguigu-maven-outer</artifactId>
    <version>1</version>
</dependency>

Copied!

创建对象、调用方法：

三、Nexus私服

http://c.biancheng.net/nexus/

1、安装

下载

https://sonatype-download.global.ssl.fastly.net/repository/downloads-prod-group/3/nexus-3.38.1-01-unix.tar.gz

https://download.sonatype.com/nexus/3/latest-unix.tar.gz

上传到linux

上传到 Linux 系统，解压后即可使用，不需要安装。但是需要注意：必须提前安装 JDK

java环境

yum install -y java-1.8.0-openjdk*
java -version
which java
ls -lr /usr/bin/java
ls -lr /etc/alternatives/java
vi /etc/profile
source /etc/profile
echo $JAVA_HOME

# /etc/profile
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-1.el7_9.x86_64
export JRE_HOME=$JAVA_HOME/jre
export CLASSPATH=$JAVA_HOME/lib:$JRE_HOME/lib:$CLASSPATH
export PATH=$JAVA_HOME/bin:$JRE_HOME/bin:$PATH

Copied!

开放端口或者禁用防火墙

1
2
3

systemctl status firewalld.service
systemctl stop firewalld.service
systemctl disable firewalld.service

Copied!

2、启动nexus

1
2
3

./nexus start
./nexus status
 cat /usr/local/opt/sonatype-work/nexus3/admin.password

Copied!

[root@x ~]# /opt/nexus-3.37.0-01/bin/nexus start WARNING: ************************************************************ WARNING: Detected execution as “root” user. This is NOT recommended! WARNING: ************************************************************ Starting nexus [root@x ~]# /opt/nexus-3.37.0-01/bin/nexus status WARNING: ************************************************************ WARNING: Detected execution as “root” user. This is NOT recommended! WARNING: ************************************************************ nexus is running.

查看端口

[root@x ~]# netstat -anp | grep java tcp 0 0 127.0.0.1:45614 0.0.0.0:* LISTEN 9872/java tcp 0 0 0.0.0.0:8081 0.0.0.0:* LISTEN 9872/java

上面 45614 这个每次都不一样，不用管它。我们要访问的是 8081 这个端口。但是需要注意：8081 端口的这个进程要在启动 /opt/nexus-3.37.0-01/bin/nexus 这个主体程序一、两分钟后才会启动，请耐心等待。

问题

解决：

vi /etc/security/limits.conf
# 末尾加
@root - nofile 65536
# 重启nexus

Copied!

root为系统用户，前面要加上@

3、访问 Nexus 首页

首页地址：http://[Linux 服务器地址]:8081/

这里参考提示：

用户名：admin
密码：查看 /opt/sonatype-work/nexus3/admin.password 文件

[root@hello ~]# cat /opt/sonatype-work/nexus3/admin.password ed5e96a8-67aa-4dca-9ee8-1930b1dd5415

给 admin 用户指定新密码：

匿名登录，启用还是禁用？由于启用匿名登录后，后续操作比较简单，这里我们演示禁用匿名登录的操作方式：

4、nexus各种库

在仓库列表中，每个仓库都具有一系列属性：

Type：仓库的类型，Nexus 中有 4 中仓库类型：group（仓库组）、hosted（宿主仓库）、proxy（代理仓库）以及 virtual（虚拟仓库）。
Format：仓库的格式。
Policy：仓库的策略，表示该仓库是发布（Release）版本仓库还是快照（Snapshot）版本仓库。
Repository Status：仓库的状态。
Repository Path：仓库的路径。

仓库类型	说明

proxy	用来代理远程公共仓库，如 Maven 中央仓库、JBoss 远程仓库。
group	用来聚合代理仓库和宿主仓库，为这些仓库提供统一的服务地址，以便 Maven 可以更加方便地获得这些仓库中的构件。
hosted	存放：本团队其他开发人员部署到 Nexus 的 jar 包

仓库名称	说明
maven-central	该仓库用来代理 Maven 中央仓库，其策略为 Release，只会下载和缓存中央仓库中的发布版本的构件
maven-public	该仓库组将上述所有存储策略为 Release 的仓库聚合并通过统一的地址提供服务
maven-releasse	策略为 Release 的宿主仓库，用来部署公司或组织内部的发布版本构件。
maven-snapshots	策略为 Snapshot 的宿主仓库，用来部署公司或组织内部的快照版本构件。

初始状态下，这几个仓库都没有内容

由上图可知：

Maven 可以直接从宿主仓库中下载构件。
Maven 也可以从代理仓库中下载构件，代理仓库会从远程仓库下载并缓存构件。
Maven 还可以从仓库组中下载构件，仓库组会从其包含的宿主仓库和代理仓库中获取构件。

5、开启索引

Nexus 作为一款成熟的仓库管理工具，它通过维护仓库的索引提供了构件搜索功能，以便帮助用户方便快速地找到所需构件。

Nexus 索引下载功能默认是关闭的，如果想在 Nexus 中搜索远程仓库中的构件，就需要先开启索引下载功能。

Nexus 能够遍历仓库的所有内容，搜集它们的坐标，校验和以及所包含的 Java 类等信息，然后以索引（ nexus-indexer）的形式保存起来。Nexus 索引保存在 Nexus 安装目录下 \sonatype-work\nexus\indexer 目录中，该目录下每个子目录都代表 Nexus 中的一个仓库，用来存放各个仓库的索引，大多数的远程公共仓库（例如，中央仓库）都维护了一个这样的索引，因此本地的 Nexus 在下载到这个索引后，就能在此基础上为用户提供构件搜索和浏览等服务。需要注意的是，并不是所有的公共仓库都提供了索引，对于那些没有提供索引的仓库来说，我们是无法对其进行搜索的。

搜索：

6、新建阿里云代理

修改maven-public

7、下载构件

两种方式：pom.xml 和 setting.xml

①、在 pom.xml 中配置

<!--声明一个或多个远程仓库  -->
<repositories>
    <!-- 声明一个 Nexus 私服上的仓库  -->
    <repository>
        <!--仓库id  -->
        <id>nexus</id>
        <!-- 仓库的名称 -->
        <name>nexus</name>
        <!--仓库的地址  -->
        <url>http://10.211.55.4:8081/repository/maven-public/</url>
        <!-- 是否开启该仓库的 release 版本下载支持 -->
        <releases>
            <enabled>true</enabled>
        </releases>
        <!-- 是否开启该仓库的 snapshot 版本下载支持 -->
        <snapshots>
            <enabled>true</enabled>
        </snapshots>
    </repository>
</repositories>
<!-- 声明一个或多个远程插件仓库 -->
<pluginRepositories>
    <!--声明一个 Nexus 私服上的插件仓库  -->
    <pluginRepository>
        <!--插件仓库 id -->
        <id>nexus</id>
        <!--插件仓库 名称 -->
        <name>nexus</name>
        <!-- 配置的插件仓库的地址 -->
        <url>http://10.211.55.4:8081/repository/maven-public/</url>
        <!-- 是否开启该插件仓库的 release 版本下载支持 -->
        <releases>
            <enabled>true</enabled>
        </releases>
        <!-- 是否开启该插件仓库的 snapshot 版本下载支持 -->
        <snapshots>
            <enabled>true</enabled>
        </snapshots>
    </pluginRepository>
</pluginRepositories>

Copied!

②、在 setting.xml 中配置

Nexus 私服通常会与镜像（mirror）结合使用，使 Nexus 成为所有远程仓库的私服，这样不仅可以从 Nexus 中获取所有所需构件，还能将配置集中到 Nexus 私服中，简化 Maven 本身的配置。

我们可以创建一个匹配任何仓库的镜像，镜像的地址为 Nexus 中仓库的地址，这样 Maven 对于任何构件的下载请求都会被拦截跳转到 Nexus 私服中，其具体配置如下。

<mirrors>
    <mirror>
        <id>nexus-mine</id>
        <name>nexus name</name>
        <mirrorOf>*</mirrorOf>
        <url>http://localhost:8082/nexus/content/groups/bianchengbang_repository_group/</url>
    </mirror>
</mirrors>

<profiles>
    <profile>
        <id>nexus</id>
        <repositories>
            <repository>
                <id>central</id>
                <url>http://localhost:8082/nexus/content/repositories/bianchengbang_central_proxy/</url>
                <releases>
                    <enabled>true</enabled>
                </releases>
                <snapshots>
                    <enabled>true</enabled>
                </snapshots>
            </repository>
        </repositories>
        <pluginRepositories>
            <pluginRepository>
                <id>central</id>
                <url>http://localhost:8082/nexus/content/repositories/bianchengbang_central_proxy/</url>
                <releases>
                    <enabled>true</enabled>
                </releases>
                <snapshots>
                    <enabled>true</enabled>
                </snapshots>
            </pluginRepository>
        </pluginRepositories>
    </profile>
</profiles>

<activeProfiles>
    <activeProfile>nexus</activeProfile>
</activeProfiles>
<servers>
        <server>
            <id>nexus-mine</id>
            <username>admin</username>
            <password>password</password>
        </server>
</servers>

Copied!

8、上传构件

首先pom.xml ：

<project>
    ...
    <distributionManagement>
        <repository>
            <id>my_releases</id>
            <url>http://10.211.55.4:8081/repository/maven-releases/</url>
        </repository>
        <snapshotRepository>
            <id>my_snapshots</id>
            <url>http://10.211.55.4:8081/repository/maven-snapshots/</url>
        </snapshotRepository>
    </distributionManagement>
</project>

Copied!

并且settings.xml ：

<servers>
    <server>
      <id>my_releases</id>
      <username>admin</username>
      <password>password</password>
    </server>
    <server>
      <id>my_snapshots</id>
      <username>admin</username>
      <password>password</password>
    </server>
</servers>

Copied!

四、复制仓库

复制仓库，jar包的mirrorId不一样，所以不会用到本地包

_remote.repositories: mine和central是mirrorId

#NOTE: This is a Maven Resolver internal implementation file, its format can be changed without prior notice.
#Mon Apr 11 19:18:31 CST 2022
hutool-all-4.5.4.jar>mine=
hutool-all-4.5.4.pom>central=
hutool-all-4.5.4.pom>mine=
hutool-all-4.5.4.jar>central=

Copied!

需要执行脚本删除lastUpdated 和 _remote.repositories

1
2
3

#!/bin/bash
find $(cd $(dirname $0); pwd) -name "*.lastUpdated" -type f -print -exec rm -rf {} \;
find $(cd $(dirname $0); pwd) -name "_remote.repositories" -type f -print -exec rm -rf {} \;

Copied!