一、构建概念和构建过程
项目构建是指将源代码、依赖库和资源文件等转换成可执行或可部署的应用程序的过程,在这个过程中包括编译源代码、链接依赖库、打包和部署等多个步骤。
项目构建是软件开发过程中至关重要的一部分,它能够大大提高软件开发效率,使得开发人员能够更加专注于应用程序的开发和维护,而不必关心应用程序的构建细节。
同时,项目构建还能够将多个开发人员的代码汇合到一起,并能够自动化项目的构建和部署,大大降低了项目的出错风险和提高开发效率。常见的构建工具包括 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、使用周期命令构建,简化构建过程,最终进行构建的是插件。