基于 IDEA 进行 Maven 工程构建

一、构建概念和构建过程

项目构建是指将源代码、依赖库和资源文件等转换成可执行或可部署的应用程序的过程，在这个过程中包括编译源代码、链接依赖库、打包和部署等多个步骤。

项目构建是软件开发过程中至关重要的一部分，它能够大大提高软件开发效率，使得开发人员能够更加专注于应用程序的开发和维护，而不必关心应用程序的构建细节。

同时，项目构建还能够将多个开发人员的代码汇合到一起，并能够自动化项目的构建和部署，大大降低了项目的出错风险和提高开发效率。常见的构建工具包括 Maven 、Gradle 、Ant等。

二、命令方式构建项目

2.1 命令总结

相关的命令总结如下：

|-------------|----------------------|
| 命令 | 描述 |
| mvn compile | 编译项目，生成 target 文件 |
| mvn package | 打包项目，生成 jar 或 war 文件 |
| mvn clean | 清理编译或打包后的项目结构 |
| mvn install | 打包后上传到 maven 本地仓库 |
| mvn deploy | 只打包，上传到 maven 私服仓库 |
| mvn site | 生成站点 |
| mvn test | 执行测试源码 |

如果 war 包打包插件和 jdk 版本不匹配，可以在pom.xml添加以下代码：

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war-plugin</artifactId>
            <version>3.2.2</version>
        </plugin>
    </plugins>
</build>

2.2 mvn compile

mvn compile 命令的作用是编译项目（只编译核心程序，不编译测试程序），生成 target 文件，并将**.java** 文件编译成 .class文件，我们演示下，首先我们引入依赖，并创建相关类，如下：

<dependency>
	<groupId>org.junit.jupiter</groupId>
	<artifactId>junit-jupiter-api</artifactId>
	<version>5.9.2</version>
	<scope>test</scope>
</dependency>
<dependency>
	<groupId>org.projectlombok</groupId>
	<artifactId>lombok</artifactId>
	<version>1.16.20</version>
	<scope>provided</scope>
</dependency>

package com.maven;

import lombok.Data;
import lombok.Getter;
import lombok.Setter;

@Data
@Setter
@Getter
public class User {
    private String name;
    private int age;
}

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;

public class MavenTest {
    
    @Test
    public void testAssert(){
        int a = 10;
        int b = 20;
        // 如果期望结果为 30，则无输出，否则直接报错
        Assertions.assertEquals(a+b,40);
    }
}

首先进入该工程的目录，然后在该目录下打开命令行，如下图：

并在命令行执行 mvn -compile ，如下图，可以看到，编译成功了，并将 .java 文件编译成了 .class 文件

2.3 mvn clean

mvn clean 命令的作用是清理编译或打包后的项目结构，我们演示下，还是在原来的目录结构下执行这个命令，看看是否可以清除掉

可以看到，target目录没有了

2.4 mvn test-compile

mvn test-compile 命令的作用是编译测试程序（不编译核心程序，只编译测试程序），生成 target 文件，并将**.java** 文件编译成 .class文件。

我们接下来演示下，首先我们可以发现，虽然我们执行了 compile命令，但是好像并没有对我们的测试代码进行编译，如下图：

此时我们再执行 mvn test-compile命令，如下，可以看到，对我们的测试程序进行了编译。

2.4 mvn test

2.4.1 案例

mvn test 命令的作用是会自动执行测试方法。我们接下来演示下，如下图，运行成功了，正确的结果应该是 30 ，但是我们断言的结果为40，所以才会报错。

将结果改为 30之后，再次执行命令，可以发现，不报错了。

2.4.2 注意

1、 调用mvn test 命令时会自动调用 mvn compile 和 mvn test-compile命令。

2、test 目录里面的测试代码是有讲究的，比如说要测试的类必须以 Test 开头或者以 Test 结尾，如果不是这样的格式，mvn test命令是无法识别的，比如下面的这个测试类。

public class MavenDemo {

    @Test
    public void testAssert(){
        int a = 10;
        int b = 20;
        // 如果期望结果为 30，则无输出，否则直接报错
        Assertions.assertEquals(a+b,30);
    }
}

都没有找到测试类，如下

3、 测试类里面的方法名也是有讲究的，以 test 开头的方法都可以识别（和方法上有没有**@Test** 注解没有关系），如果是随便起的或者 test在方法后面的都无法识别，如下

public class MavenTest {

    @Test
    public void aaa(){
        int a = 10;
        int b = 20;
        // 如果期望结果为 30，则无输出，否则直接报错
        Assertions.assertEquals(a+b,30);
    }
}

方法后面加 test，如下：

public class MavenTest {

    @Test
    public void assertTest(){
        int a = 10;
        int b = 20;
        // 如果期望结果为 30，则无输出，否则直接报错
        Assertions.assertEquals(a+b,30);
    }
}

2.5 报告

maven项目构建有一个阶段是报告，这个报告就是记录我们测试的结果，我们并不用使用具体的指令来实现报告的过程，执行测试之后会自动执行测试的结果，可以执行下面的命令先清理再进行测试

mvn clean test

执行结束后会在 target 目录下生成一个 surefire-reports文件夹，它里面存储的就是测试的结果

这个就是具体的报告

2.6 打包

打包的意思就是把我们的工程构建成 jar 或者 war ，它所对应的命令为 mvn package，

需要注意的是，在进行打包操作时，它首先会将核心代码和测试代码编译，还会执行我们的测试代码。换句话说就是一次打包会进行多次操作。

2.6.1 构建 jar 包

生成一个新的 jar包，如下。

在最终构建成的 jar 或者 war包里面，都是没有测试程序的。

2.6.2 构建 war 包

切换到 web 模块下，构建成 war包，如下所示：

2.7 安装

安装的意思就是把我们上面构建成的 jar 包或者 war包安装到本地仓库里面。在介绍这个之间，先来看下下面的场景。

现在的项目结构如下所示，maven_java 是一个模块，maven_web是一个模块，如下：

如果我想在 maven_web 模块里面使用 maven_java 里面的相关 api ，只需要在 maven_web 的 pom.xml 里面引入 maven_java的依赖即可，如下：

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.maven</groupId>
    <artifactId>maven_web</artifactId>
    <version>1.0-SNAPSHOT</version>

    <packaging>war</packaging>

    <properties>
        <maven.compiler.source>8</maven.compiler.source>
        <maven.compiler.target>8</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>
    <dependencies>
        <!-- 引入 maven_java 依赖-->
        <dependency>
            <groupId>com.maven</groupId>
            <artifactId>maven_java</artifactId>
            <version>1.0-SNAPSHOT</version>
        </dependency>
    </dependencies>
</project>

接下来对 maven_web模块进行打包操作，如下：

可以发现报错了，是因为在打包的过程中没有发现 maven_java 这个依赖，在打包的过程中需要先去本地仓库寻找 jar包，如果没有找到则去中央仓库寻找。这两个地方都没有，因为这是我们自己的模块，怎么可能有。

这个时候就需要用到我们的mvn install 命令了。它会将我们的 jar 包或者 war包安装到本地仓库。

进入到 maven_java 模块的目录下，执行mvn install 命令，就可以将我们的工程打成 jar包并放到本地仓库里面，如下：

在本地仓库里面可以看见我们安装的 jar包，如下：

此时，我们再次编译 maven_web项目，就成功了，如下：

2.8 打包和安装区别

1、 打包是将工程打成 jar 或 war 文件，保存在 target目录下

2、 安装是将当前工程所生成的 jar 或 war文件，安装到本地仓库，会按照坐标保存到指定位置

三、可视化方式构建项目

打开 idea ，点击右侧的 Maven ，如下，Lifecycle 的意思是生命周期，Plugins 是插件，Dependencies是项目的依赖。

3.1 Lifecycle

生命周期里面的命令有些和我们的命令一样，有些不一样，比如 validate 和 verify 是对我们的 maven工程进行验证用的，其他的命令基本都一样。

3.2 Plugins

插件里面的命令和生命周期里面的命令基本一样，这些都是我们的 maven 工程中默认的插件，是用来支持生命周期的插件，点击插件里面的 clean 命令和点击生命周期里面的 clean命令效果一样。

四、构建插件、命令和生命周期之间的关系

4.1 构建生命周期

我们发现一个情况，当我们执行 package 命令也会自动执行 compile命令，如下图

这种行为就是因为构建生命周期产生的！构建生命周期可以理解成是一组固定构建命令的有序集合，触发周期后的命令，会自动触发周期前的命令。

4.2 构建周期作用

构建周期会简化构建过程。比如说项目打包，只需要执行 mvn clean package即可。主要包含两个构建生命周期。

1、 清理周期：主要是对项目编译生成文件进行清理，如 clean。

2、 默认周期：定义了真正构件时所需要执行的所有步骤，它是生命周期中最核心的部分，如 compile - test - package - install - deploy 等。

4.3 插件、命令、周期三者关系

**1、**周期 → 包含若干命令 → 包含若干插件

**2、**使用周期命令构建，简化构建过程，最终进行构建的是插件。