此版本仍在开发中，尚未被视为稳定版本。对于最新的稳定版本，请使用 Spring Boot 3.4.3！

打包可执行存档文件

该插件可以创建包含应用程序所有依赖项的可执行存档（jar 文件和 war 文件），然后可以使用java -jar.

打包可执行 Jar

可执行 jar 可以使用bootJar任务。 当javaplugin 的实例，并且是BootJar. 这assembletask 会自动配置为依赖于bootJar任务如此运行assemble（或build） 也会运行bootJar任务。

打包可执行 Wars

可执行 wars 可以使用bootWar任务。 当warplugin 的实例，并且是BootWar. 这assembletask 会自动配置为依赖于bootWar任务如此运行assemble（或build） 也会运行bootWar任务。

打包可执行和可部署的 War

可以打包 war 文件，以便可以使用java -jar并部署到外部容器。 为此，应将嵌入式 servlet 容器依赖项添加到providedRuntimeconfiguration，例如：

dependencies {
	implementation('org.springframework.boot:spring-boot-starter-web')
	providedRuntime('org.springframework.boot:spring-boot-starter-tomcat')
}

这确保了它们被打包在 war 文件的WEB-INF/lib-provided目录中，它们不会与外部容器自己的类冲突。

providedRuntime比 Gradle 的compileOnly配置，除其他限制外，compileOnly依赖项不在测试 Classpath 上，因此任何基于 Web 的集成测试都将失败。

打包可执行存档和普通存档

默认情况下，当bootJar或bootWar任务配置后，该jar或war任务配置为使用plain作为其档案分类器的约定。 这可确保bootJar和jar或bootWar和war具有不同的输出位置，从而允许同时构建 Executable Archive 和 Plain Archive。

如果您希望可执行存档（而不是普通存档）使用分类器，请按照以下示例所示为jar和bootJar任务：

tasks.named("bootJar") {
	archiveClassifier = 'boot'
}

tasks.named("jar") {
	archiveClassifier = ''
}

或者，如果您希望根本不构建 plain 存档，请禁用其任务，如以下示例所示。jar任务：

tasks.named("jar") {
	enabled = false
}
请勿禁用jartask 创建原生镜像时执行。 有关详细信息，请参阅 #33238。

配置可执行归档文件打包

这BootJar和BootWartasks 是 Gradle 的Jar和War任务。 因此，打包 jar 或 war 时可用的所有标准配置选项在打包可执行 jar 或 war 时也可用。 还提供了许多特定于可执行 jar 和 war 的配置选项。

配置 Main 类

默认情况下，可执行存档的主类将通过查找具有public static void main(String[])方法。

主类也可以使用任务的mainClass财产：

tasks.named("bootJar") {
	mainClass = 'com.example.ExampleApplication'
}

或者，可以使用mainClassSpring Boot DSL 的属性：

springBoot {
	mainClass = 'com.example.ExampleApplication'
}

如果application插件已应用其mainClass属性，并且可用于相同的目的：

application {
	mainClass = 'com.example.ExampleApplication'
}

最后，Start-Class属性：

tasks.named("bootJar") {
	manifest {
		attributes 'Start-Class': 'com.example.ExampleApplication'
	}
}
如果主类是用 Kotlin 编写的，则应使用生成的 Java 类的名称。 默认情况下，这是 Kotlin 类的名称，其中Kt后缀已添加。 例如ExampleApplication成为ExampleApplicationKt. 如果使用@JvmName那么应该使用那个 name。

包括仅限开发的依赖项

默认情况下，在developmentOnlyconfiguration 将从可执行的 jar 或 war 中排除。

如果要包含在developmentOnlyconfiguration 中，配置其任务的 Classpath 以包含配置，如以下示例所示。bootWar任务：

tasks.named("bootWar") {
	classpath configurations.developmentOnly
}

配置需要解包的库

大多数库嵌套在可执行存档中时可以直接使用，但某些库可能会出现问题。 例如，JRuby 包含它自己的嵌套 jar 支持，它假定jruby-complete.jar始终在文件系统上直接可用。

为了处理任何有问题的库，可以配置一个可执行存档，以便在运行可执行存档时将特定的嵌套 jar 解压缩到临时目录。 可以使用与源 jar 文件的绝对路径匹配的 Ant 样式模式将库标识为需要解包：

tasks.named("bootJar") {
	requiresUnpack '**/jruby-complete-*.jar'
}

为了获得更多控制，也可以使用闭包。 闭包会传递一个FileTreeElement并应返回一个boolean指示是否需要解压缩。

使归档文件完全可执行

Spring Boot 提供对完全可执行存档的支持。 通过预置知道如何启动应用程序的 shell 脚本，可以使存档完全可执行。 在类 Unix 平台上，此启动脚本允许存档像任何其他可执行文件一样直接运行或作为服务安装。

目前，某些工具不接受此格式，因此您可能并不总是能够使用此技术。 例如jar -xf可能会静默地无法提取已完全可执行的 jar 或 war。 建议您仅在打算直接执行此选项时启用此选项，而不是使用java -jar或将其部署到 servlet 容器。

要使用此功能，必须启用包含启动脚本：

tasks.named("bootJar") {
	launchScript()
}

这会将 Spring Boot 的默认启动脚本添加到存档中。 默认启动脚本包括多个具有合理默认值的属性。 可以使用properties财产：

tasks.named("bootJar") {
	launchScript {
		properties 'logFilename': 'example-app.log'
	}
}

如果默认启动脚本不能满足您的需求，则script属性可用于提供自定义启动脚本：

tasks.named("bootJar") {
	launchScript {
		script = file('src/custom.script')
	}
}

使用 PropertiesLauncher

要使用PropertiesLauncher要启动可执行的 jar 或 war，请配置任务的清单以设置Main-Class属性：

tasks.named("bootWar") {
	manifest {
		attributes 'Main-Class': 'org.springframework.boot.loader.launch.PropertiesLauncher'
	}
}

打包分层 Jar 或 War

默认情况下，bootJartask 会构建一个存档，其中包含应用程序的类和依赖项BOOT-INF/classes和BOOT-INF/lib分别。 同样地bootWar构建一个包含应用程序类的存档WEB-INF/classes和依赖项WEB-INF/lib和WEB-INF/lib-provided. 对于需要从 jar 的内容构建 docker 镜像的情况，能够进一步分离这些目录以便将它们写入不同的层非常有用。

分层 jar 使用与常规引导打包 jar 相同的布局，但包含一个描述每个层的附加元数据文件。

默认情况下，定义了以下图层：

层顺序非常重要，因为它决定了当应用程序的一部分发生更改时，可以缓存先前层的可能性。 默认顺序为dependencies,spring-boot-loader,snapshot-dependencies,application. 应首先添加最不可能更改的内容，然后添加更有可能更改的图层。

要禁用此功能，您可以通过以下方式执行此作：

tasks.named("bootJar") {
	layered {
		enabled = false
	}
}

创建分层 jar 或 war 时，spring-boot-jarmode-toolsjar 将作为依赖项添加到您的存档中。 在 Classpath 上使用此 jar，您可以以特殊模式启动应用程序，该模式允许引导代码运行与应用程序完全不同的东西，例如，提取层的东西。 如果您希望排除此依赖项，可以通过以下方式进行：

tasks.named("bootJar") {
	includeTools = false
}

自定义图层配置

根据您的应用程序，您可能希望调整层的创建方式并添加新层。

这可以使用描述如何将 jar 或 war 分成层以及这些层的顺序的配置来完成。 以下示例显示了如何显式定义上述默认 Sequences：

tasks.named("bootJar") {
	layered {
		application {
			intoLayer("spring-boot-loader") {
				include "org/springframework/boot/loader/**"
			}
			intoLayer("application")
		}
		dependencies {
			intoLayer("application") {
				includeProjectDependencies()
			}
			intoLayer("snapshot-dependencies") {
				include "*:*:*SNAPSHOT"
			}
			intoLayer("dependencies")
		}
		layerOrder = ["dependencies", "spring-boot-loader", "snapshot-dependencies", "application"]
	}
}

这layeredDSL 由三个部分定义：

嵌 套intoLayer闭包用于application和dependencies部分以声明图层的内容。 这些 Closure 按照定义的顺序从上到下进行评估。 任何未被早期用户认领的内容intoLayerclosure 仍可供后续考虑。

这intoLayer使用嵌套的 Closure 声明内容include和exclude调用。 这applicationclosure 对 include/exclude 参数使用 Ant 样式的路径匹配。 这dependencies部分用途group:artifact[:version]模式。 它还提供includeProjectDependencies()和excludeProjectDependencies()可用于包含或排除项目依赖项的方法。

如果没有include调用，则考虑所有内容（未被早期闭包认领）。

如果没有exclude调用，则不会应用任何排除项。

查看dependenciesclosure 中，我们可以看到第一个intoLayer将声明application层。 下一个intoLayer将声明snapshot-dependencies层。 第三次也是最后一次intoLayer将声明dependencies层。

这applicationclosure 也有类似的规则。 首次认领org/springframework/boot/loader/**content 的spring-boot-loader层。 然后为application层。

订单intoLayer添加闭包通常与层的写入顺序不同。 因此，layerOrder方法必须始终调用，并且必须覆盖intoLayer调用。

APP信息