spring-boot-maven-plugin
我们直接使用 maven package （maven自带的package打包功能），打包Jar包的时候，不会将该项目所依赖的Jar包一起打进去，在使用java -jar命令启动项目时会报错，项目无法正常启动。这个时候，我们就可以考虑引用spring-boot-maven-plugin插件来为项目打Jar包。
maven项目的pom.xml中，添加了下述插件，当运行 maven package 进行打包时，会打包成一个可以直接运行的JAR（fat jar）文件，使用 java -jar 命令就可以直接运行。
注意：如果你的项目没有继承spring-boot-starter-parent 这个POM，你需要做如下配置，将目标绑定到repackage。
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
默认情况下maven项目的打包命令，在打Jar包时不会把依赖的jar包也打包进去，但是spring-boot-maven-plugin插件，会将依赖的jar包全部打包进去。例如下面这个使用spring-boot-maven-plugin插件打包生成的jar包的BOOT/INF/lib目录下面就包含了所有依赖的jar包：
引入了spring-boot-maven-plugin插件后，在使用打包功能时会将mvn package 生成的 jar或者war 重新打包成可执行文件，同时修改原文件名，增加.origin 后缀。
可执行 Jar 包内部结构
将打出来的可执行 Jar 解压开我们能看到下面的结构：
可执行 jar 目录结构
├─BOOT-INF
│ ├─classes
│ └─lib
├─META-INF
│ ├─maven
│ ├─app.properties
│ ├─MANIFEST.MF
└─org
└─springframework
└─boot
└─loader
├─archive
├─data
├─jar
└─util
结构对比
从上面的文件结构和 jar 清单内容来看，Spring Boot 打包后的 fatjar 对比 源 jar 主要有以下差异：
- 源 jar 中主项目的
.class文件被移至fatjar的BOOT-INF/classes文件夹下。 - 新增
BOOT-INF/lib文件夹，里面存放三方 jar 文件。 - 新增
BOOT-INF/classpath.idx，用来记录classpath的加载顺序。 - 新增
org/springframework/boot/loader文件夹，这是spring-boot-loader编译后的 .class 文件。 - 清单文件
MANIFEST.MF中新增以下属性: Spring-Boot-Classpath-Index: 记录classpath.idx文件的地址。Start-Class: 指定Spring Boot的启动类。Spring-Boot-Classes: 记录主项目的.class文件存放路径。Spring-Boot-Lib: 记录三方 jar 文件存放路径。Spring-Boot-Version: 记录Spring Boot版本信息Main-Class: 指定 jar 程序的入口类（可执行 jar 为org.springframework.boot.loader.JarLauncher类）。
我们先来重点关注两个地方：META-INF 下面的 Jar 包描述文件和 BOOT-INF 这个目录。
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Built-By: xxxx
Start-Class: com.xxxx.AppServer
Spring-Boot-Classes: BOOT-INF/classes/
Spring-Boot-Lib: BOOT-INF/lib/
Spring-Boot-Version: 2.1.6.RELEASE
Created-By: Apache Maven 3.3.9
Build-Jdk: 1.8.0_73
Main-Class: org.springframework.boot.loader.JarLauncher
在上面我们看到一个熟悉的配置Main-Class: org.springframework.boot.loader.JarLauncher。我们大概能猜到这个类是整个系统的入口。
再看下 BOOT-INF 这个目录下面，我们会发现里面是我们项目打出来的 class 文件和项目依赖的 Jar 包。看到这里，你可能已经猜到 Spring Boot 是怎么启动项目的了。
Spring Boot 是怎么启动项目
JarLauncher
public class JarLauncher extends ExecutableArchiveLauncher {
static final String BOOT_INF_CLASSES = "BOOT-INF/classes/";
static final String BOOT_INF_LIB = "BOOT-INF/lib/";
public JarLauncher() {
}
protected JarLauncher(Archive archive) {
super(archive);
}
@Override
protected boolean isNestedArchive(Archive.Entry entry) {
if (entry.isDirectory()) {
return entry.getName().equals(BOOT_INF_CLASSES);
}
return entry.getName().startsWith(BOOT_INF_LIB);
}
public static void main(String[] args) throws Exception {
//项目入口，重点在launch这个方法中
new JarLauncher().launch(args);
}
}
//launch方法
protected void launch(String[] args) throws Exception {
JarFile.registerUrlProtocolHandler();
//创建LaunchedURLClassLoader。如果根类加载器和扩展类加载器没有加载到某个类的话，就会通过LaunchedURLClassLoader这个加载器来加载类。这个加载器会从Boot-INF下面的class目录和lib目录下加载类。
ClassLoader classLoader = createClassLoader(getClassPathArchives());
//这个方法会读取jar描述文件中的Start-Class属性，然后通过反射调用到这个类的main方法。
launch(args, getMainClass(), classLoader);
}
简单总结
-
Spring Boot 可执行 Jar 包的入口点是 JarLauncher 的 main 方法；
-
这个方法的执行逻辑是先创建一个 LaunchedURLClassLoader，这个加载器加载类的逻辑是：
先判断根类加载器和扩展类加载器能否加载到某个类，如果都加载不到就从 Boot-INF 下面的 class 和 lib 目录下去加载；
-
读取Start-Class属性，通过反射机制调用启动类的 main 方法，这样就顺利调用到我们开发的 Spring Boot 主启动类的 main 方法了。
Goal
spring-boot-maven-plugin 官方文档 介绍的有五种 goal，分别如下：
- spring-boot:build-image: 将程序使用 buildpack 打包进容器镜像中。
- spring-boot:build-info: 根据当前 MavenProject 的内容生成一个 build-info.properties 文件
- spring-boot:help: 显示帮助信息。调用mvn spring-boot:help -Ddetail=true -Dgoal=以显示参数详细信息。
- spring-boot:repackage: 默认的 goal，将普通 mvn package 打包成的 jar 重新打包成包含所有程序依赖项的可执行 jar/war 文件，并保留 mvn package 打包的 jar 为 .original 后缀
- spring-boot:run: 运行 Spring Boot 应用。
- spring-boot:start: 通常用于集成测试方案中，在 mvn integration-test 阶段管理 Spring Boot 应用的生命周期。
- spring-boot:stop: 停止已通过 start 目标启动的应用程序。通常在 integration-test 完成后调用。
文章只对 repackage 进行分析，我们先直接看下 spring-boot-maven-plugin 的源代码结构:
spring-boot-maven-plugin：打包时排除provided依赖
spring-boot-maven-plugin 插件提供spring boot的maven打包支持。项目中scope为provided的依赖，比如 lombok、mybatis-plus 等，只作用于编译阶段，编译完成就可以功成身退了。在spring maven打包时，provided依赖会排除在包外，但springboot maven打包时，还会将这些依赖打进 war 包的 lib-provided 文件夹里或 jar 包的 lib 文件夹里。
springboot项目构建jar包或war包的命令为repackage，作用于maven生命周期的package阶段，在 mvn package 执行之后，这个命令再次打包生成可执行的包，例如打jar包时，生成可执行jar包，同时将 mvn package 生成的 jar 重命名为 *.origin。默认情况下，repackage会将工程中引入的任何依赖打到包中。
以lombok为例，官方提供了以下方式可以将provided依赖从springboot项目包中排除。
1. 通过指定groupId和artifactId排除某个特定的依赖
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<excludes>
<exclude>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
</exclude>
</excludes>
</configuration>
</plugin>
</plugins>
</build>
2. 指定groupId排除groupId相关的所有依赖
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<excludeGroupIds>org.projectlombok</excludeGroupIds>
</configuration>
</plugin>
</plugins>
</build>
2. 按照配置文件排除依赖
<profiles>
<profile>
<id>dev</id>
<activation>
<property>
<name>environment</name>
<value>dev</value>
</property>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>2.7.12</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
<configuration>
<excludes>
<exclude>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
</exclude>
</excludes>
</configuration>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>prod</id>
<activation>
<property>
<name>environment</name>
<value>prod</value>
</property>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>2.7.12</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
<configuration>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
mvn clean package -Pdev 使用dev配置文件去除lombok 依赖
SpringBoot 工程部署的 jar 包瘦身
通过上方分析 fat jar下 有 classes，lib 两个文件夹，我们编译好的代码是放在 classes 里面的，而我们所依赖的 jar 包都是放在 lib 文件夹下
classes 部分是非常小的（我的是160kb左右），lib部分是非常大的（我的是70M左右），所以上传很慢
那我们可以将我们自己写的代码部分与所依赖的 maven jar 包部分拆开上传，每次只需要上传我们自己写的代码部分即可
正常打包
首先，我们项目的 pom.xml 文件中的打包方式如下：
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
这是 SpringBoot 中默认的打包方式，我们先按照这种方式打包出来，得到一个 jar 包，我们将 jar 包解压，如果不能直接解压，则将后缀改为 zip 再进行解压，我们只需要拿到 BOOT-INF 中的 lib 目录即可
改变打包方式
我们对 SpringBoot 中默认的打包方式做一些配置
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<mainClass>com.Application</mainClass>
<layout>ZIP</layout>
<includes>
<include>
<groupId>nothing</groupId>
<artifactId>nothing</artifactId>
</include>
</includes>
</configuration>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
mainClass，我们指定了项目的启动类layout，我们指定了打包方式为 ZIP，注意：一定是大写的includes，有自己的依赖 jar，可以在此导入repackage，剔除其它的依赖，只需要保留最简单的结构
再次打包
我们再次点击 maven package，得到一个 jar 包，可以看到此时的 jar 包只有167kb了(原先70M+)
上传启动
我们将 lib 目录，以及最后打包的瘦身项目 jar 包，上传至服务器同一目录
使用命令
nohup java -Dloader.path=./lib -jar ./sbm-0.0.1-SNAPSHOT.jar &
-Dloader.path，告诉它所依赖的 maven jar 包位置admin4j-example-1.0.jar，项目 jar 包的名字nohup、&，使得 jar 包在服务后台运行
总结
使用瘦身部署，方便每次的迭代更新，不用每次都上传一个很大的 jar 包，从而节省部署时间。但是每次依赖jar包版本或者有新增了，需要更改下lib目录数据
2633
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
