|
对于最新稳定版本，请使用Spring Boot 4.0.0！ |
可执行档案打包
该插件可以创建包含应用程序所有依赖的可执行档案（jar 文件和 war 文件），并可运行于Java -jar.
可执行档案的打包由重新包装目标，如下例所示：
<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>这重新包装目标并非仅在命令行中使用，因为它在源代码上运行罐（或战争） 由包阶段。
要在命令行中使用该目标，必须包含包阶段：MVN package Spring-boot：repackage. |
如果你正在使用Spring靴启动父，这样的执行已经预设为重新包装执行 ID，这样只需添加插件定义。 |
上述示例重新打包了罐或战争在 Maven 生命周期的包阶段构建的档案，包括任何提供项目中定义的依赖关系。
如果需要排除某些依赖关系，你可以使用其中一种排除选项;详情请参见依赖排除条款。
原始（即不可执行）工件被重命名为。源语言默认情况下，但也可以使用自定义分类器保留原始工件。
这输出文件名称映射特征Maven-War插件目前不支持。 |
这Spring-boot-devtools和Spring-boot-docker-compose模块默认会自动排除（你可以用exclusionDevtools和exclusionDockerCompose性质）。
为了让它与战争包装，以及Spring-boot-devtools和Spring-boot-docker-compose依赖关系必须设置为自选或者提供范围。
插件会重写你的清单，特别是它管理主级和起始级条目。
如果默认值不行，你必须在 Spring Boot 插件里配置值，而不是在 jar 插件里。
这主级在清单中，由布局Spring Boot 插件的属性，如下示例所示：
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<mainClass>${start.class}</mainClass>
<layout>ZIP</layout>
</configuration>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>这布局属性默认为归档类型决定的值（罐或战争).以下布局可供选择：
-
罐： 常规可执行的 JAR 布局。 -
战争：可执行的WAR布局。提供依赖关系被放置在WEB-INF/lib-提供的以避免在战争部署在 servlet 容器中。 -
ZIP（别名为迪尔：类似于罐布局使用PropertiesLauncher. -
没有：捆绑所有依赖和项目资源。它不会捆绑引导加载器。
层叠罐或战争
重新打包的jar包含应用程序的类和依赖关系启动-INF/类和启动-INF/LIB分别。
同样，可执行的战争包含应用的类网络基础/课程以及WEB-INF/LIB和WEB-INF/lib-提供的.
对于需要从jar或war内容构建docker镜像的情况，能够进一步分离这些目录以便将它们写入不同的层是很有用的。
分层档案使用与普通重新打包的jar或war相同的布局，但包含一个额外的元数据文件来描述每一层。
默认情况下，定义了以下层：
-
依赖对于任何版本不包含快照. -
Spring Boot加载器关于装载机课程。 -
快照依赖关系对于任何版本包含快照. -
应用用于本地模块依赖、应用类和资源。
模块依赖通过查看当前构建中的所有模块来识别。 如果模块依赖只能因为安装在 Maven 本地缓存中且不属于当前构建而被解决，则该依赖将被识别为常规依赖。
层次序很重要，因为它决定了当应用部分发生变化时，前一层被缓存的可能性。
默认顺序为依赖,Spring Boot加载器,快照依赖关系,应用.
最不可能改变的内容应先添加，然后是更可能变化的图层。
重新包装的档案包括layers.idx默认文件。
要禁用此功能，您可以以下方式作：
<project>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<layers>
<enabled>false</enabled>
</layers>
</configuration>
</plugin>
</plugins>
</build>
</project>自定义图层配置
根据你的应用，你可能需要调整图层的创建方式并添加新的图层。 这可以通过一个单独的配置文件完成，该配置文件应如下所示注册：
<project>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<layers>
<enabled>true</enabled>
<configuration>${project.basedir}/src/layers.xml</configuration>
</layers>
</configuration>
</plugin>
</plugins>
</build>
</project>配置文件描述了如何将归档拆分为多个层，以及这些层的顺序。 以下示例展示了上述默认排序如何被明确定义：
<layers xmlns="http://www.springframework.org/schema/boot/layers"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/boot/layers
https://www.springframework.org/schema/boot/layers/layers-3.3.xsd">
<application>
<into layer="spring-boot-loader">
<include>org/springframework/boot/loader/**</include>
</into>
<into layer="application" />
</application>
<dependencies>
<into layer="application">
<includeModuleDependencies />
</into>
<into layer="snapshot-dependencies">
<include>*:*:*SNAPSHOT</include>
</into>
<into layer="dependencies" />
</dependencies>
<layerOrder>
<layer>dependencies</layer>
<layer>spring-boot-loader</layer>
<layer>snapshot-dependencies</layer>
<layer>application</layer>
</layerOrder>
</layers>这层XML格式定义为三个部分：
-
这
<应用吗>Block 定义了应用类和资源应如何分层。 -
这
<依赖关系>块定义了依赖应如何分层。 -
这
<层次>块定义了图层应写入的顺序。
嵌 套<进>区块被用于<应用吗>和<依赖关系>用来认领图层内容的部分。
这些区块按定义顺序从上到下进行评估。
任何未被之前块认领的内容仍可供后续块考虑。
这<进>使用嵌套方式阻止声明内容<包括>和<排除>元素。
这<应用吗>该节使用Ant式路径匹配来实现include/exclude表达式。
这<依赖关系>节段用途Group：Artifact[：version]模式。
它还提供<includeModuleDependencies />和<exclusionModuleDependencies />可用于包含或排除局部模块依赖的元素。
如果没有<包括>定义后，考虑所有内容（未被早期块占领）。
如果没有<排除>定义后，则不应用排除项。
正在看<依赖关系>上例，我们可以看到第一个<进>将对application.layer.
下一个<进>将对快照依赖关系层。
决赛<进>将对剩余的（在此例中，任何非快照的依赖）来获取依赖层。
这<应用吗>Block有类似的规则。
首次宣称org/springframework/boot/loader/**内容包括Spring Boot加载器层。
然后申领剩余的职业和资源应用层。
顺序是<进>块的定义通常与层的写入顺序不同。
因此<层次>元素必须始终包含，并且必须覆盖所有由<进>块。 |
spring-boot：repackage
org.springframework.boot：spring-boot-maven-plugin：3.3.13
重新打包现有的JAR和WAR归档，使其可以通过命令行执行Java -jar.跟布局=无也可以简单地用来打包带有嵌套依赖的 JAR（且没有主类，因此不可执行）。
可选参数
| 名称 | 类型 | 默认值 |
|---|---|---|
|
|
|
|
||
|
||
|
||
|
|
|
|
|
|
|
||
|
||
|
|
|
|
|
|
|
|
|
|
||
|
||
|
|
|
|
||
|
|
参数细节
附加
将重新打包的归档文件附加到本地 Maven 仓库或部署到远程仓库。如果没有分类器配置，它将替换普通的罐子。如果分类已经配置成普通罐子和重新包装的罐子不同，它会和普通罐子一起连接。当该属性被设置为false，重新打包后的归档不会被安装或部署。
名称 |
|
|---|---|
类型 |
|
默认值 |
|
用户属性 |
|
因为 |
|
分类
分类器，添加到重新打包的档案中。如果未提供，主文物将被重新包装的档案取代。如果给定了分类器，该分类器还将用于确定要重新打包的源档案：如果已有带有该分类器的工件，将作为源使用并替换。如果不存在此类工件，主工件将作为源，重新打包后的档案将作为补充工件附加到该分类器中。附加该神器后，可以将其与原始神器并放，详情请参见Maven文档。
名称 |
|
|---|---|
类型 |
|
默认值 |
|
用户属性 |
|
因为 |
|
嵌入启动脚本
嵌入的启动脚本如果是完全可执行的话，可以直接在jar的前端做前置。如果未指定，将使用默认脚本“Spring Boot”。
名称 |
|
|---|---|
类型 |
|
默认值 |
|
用户属性 |
|
因为 |
|
exclusionDevtools
从重新打包的压缩包中排除 Spring Boot 开发工具。
名称 |
|
|---|---|
类型 |
|
默认值 |
|
用户属性 |
|
因为 |
|
exclusionDockerCompose
从重新打包的压缩包中排除 Spring Boot 开发服务。
名称 |
|
|---|---|
类型 |
|
默认值 |
|
用户属性 |
|
因为 |
|
exclusionGroupIds
逗号分隔的groupid名称列表，排除（完全匹配）。
名称 |
|
|---|---|
类型 |
|
默认值 |
|
用户属性 |
|
因为 |
|
排除
排除的工件定义集合。这排除元素定义了强制性组ID和artifactId（遗物ID组件和可选分类元件。当配置为属性时，值应以逗号分隔，并用冒号分隔：groupId：artifactId，groupId：artifactId：分类器
名称 |
|
|---|---|
类型 |
|
默认值 |
|
用户属性 |
|
因为 |
|
可执行
通过在 jar 前加上启动脚本，为 *nix 机器制作一个完全可执行的 jar。目前，有些工具不支持这种格式，所以你可能并不总是能使用这种方法。例如jar -xf可能默默地未能提取一个已完全可执行的罐子或战争。建议只有在你打算直接执行时才启用此选项，而不是用Java -jar或者部署到Servlet容器中。
名称 |
|
|---|---|
类型 |
|
默认值 |
|
用户属性 |
|
因为 |
|
包括
包含工件定义的集合。这包括元素定义了强制性组ID和artifactId（遗物ID组件和可选分类元件。当配置为属性时，值应以逗号分隔，并用冒号分隔：groupId：artifactId，groupId：artifactId：分类器
名称 |
|
|---|---|
类型 |
|
默认值 |
|
用户属性 |
|
因为 |
|
布局
归档类型（对应于其内部依赖的布局）。可能的值有罐,战争,ZIP,迪尔,没有.默认根据档案类型进行猜测。
名称 |
|
|---|---|
类型 |
|
默认值 |
|
用户属性 |
|
因为 |
|
outputDirectory
目录包含生成的归档。
名称 |
|
|---|---|
类型 |
|
默认值 |
|
用户属性 |
|
因为 |
|
输出时间戳
可重复输出归档条目的时间戳，格式为ISO 8601 （yyyy-mm-dd'T'HH：mm：ssXXX）或一个智力代表自纪元以来的秒。
名称 |
|
|---|---|
类型 |
|
默认值 |
|
用户属性 |
|
因为 |
|
例子
自定义分类器
默认情况下，重新包装Goal用重新包装的Artifact替换了原有的Artid。
对于代表应用的模块来说，这是合理的行为，但如果你的模块作为另一个模块的依赖，你需要为重新打包的模块提供分类器。
原因是应用类被打包在启动-INF/类这样依赖模块就无法加载重新打包的jar的类。
如果是这样，或者你更愿意保留原始工件并用不同的分类器附加重新打包的工件，请按照以下示例配置插件：
<project>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<id>repackage</id>
<goals>
<goal>repackage</goal>
</goals>
<configuration>
<classifier>exec</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>如果你正在使用Spring靴启动父这重新包装目标在带有 ID 的执行中自动执行重新包装.
在该配置中，只需指定配置，如下示例所示：
<project>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<id>repackage</id>
<configuration>
<classifier>exec</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>该配置会产生两个工件：原始工件和由重打包目标产生的重新打包对应部分。 两者都会透明地安装和部署。
如果你想用和替换主工件相同的方式重新打包次要工件，也可以用同样的配置。
以下配置可安装/部署单个任务带有重新包装应用的机密伪影：
<project>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
<phase>package</phase>
<configuration>
<classifier>task</classifier>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<id>repackage</id>
<goals>
<goal>repackage</goal>
</goals>
<configuration>
<classifier>task</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>作为Maven-jar-plugin以及Spring-boot-Maven-插件在同一阶段运行时，重要的是先定义 jar 插件（这样它会在重打包目标之前运行）。
同样，如果你正在使用这些Spring靴启动父，可以简化为：
<project>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<id>default-jar</id>
<configuration>
<classifier>task</classifier>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<id>repackage</id>
<configuration>
<classifier>task</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>自定义名称
如果你需要重新打包的jar拥有与定义的不同本地名称，artifactId（遗物ID项目属性，使用标准最终名称如下例所示：
<project>
<build>
<finalName>my-app</finalName>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<id>repackage</id>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>该配置将生成重新打包后的工件目标/my-app.jar.
本地重新包装的文物
默认情况下，重新包装目标用可执行的工件替换原始工件。
如果你只需要部署原始jar，但又能用普通文件名运行应用，请按照以下方式配置插件：
<project>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<id>repackage</id>
<goals>
<goal>repackage</goal>
</goals>
<configuration>
<attach>false</attach>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>这种配置会产生两个工件：原始的工件和由重新包装目标。
只会安装/部署原来的。
自定义布局
Spring Boot 通过附加 jar 文件中定义的自定义布局工厂重新打包了 jar 文件，作为构建插件的依赖：
<project>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<id>repackage</id>
<goals>
<goal>repackage</goal>
</goals>
<configuration>
<layoutFactory implementation="com.example.CustomLayoutFactory">
<customProperty>value</customProperty>
</layoutFactory>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.example</groupId>
<artifactId>custom-layout</artifactId>
<version>0.0.1.BUILD-SNAPSHOT</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</project>布局工厂作为布局工厂（摘自Spring Boot加载工具）在pom中明确指定。
如果只有一个习俗布局工厂在插件 classpath 上，并且它被列在META-INF/spring.factories那么就不需要在插件配置中明确设置它。
如果设置了明确布局，布局工厂总是被忽略。
依赖排除
默认情况下，两者重新包装以及执行目标将包括任何提供项目中定义的依赖关系。
春季启动项目应考虑提供依赖作为运行应用所需的“容器”依赖。
一般来说，Spring Boot 项目不被用作依赖，因此不太可能存在任何依赖自选依赖。
当项目确实存在可选依赖时，它们也会被包含在重新包装和执行目标。
其中一些依赖可能根本不需要，应从可执行jar中剔除。 为了保持一致性，运行应用程序时也不应有这些问题。
有两种方法可以排除依赖在运行时被打包/使用：
-
排除特定文物，识别为
组ID和artifactId（遗物ID，可选地带有一个分类如果需要的话。 -
排除属于某一特定物品的任何文物
组ID.
以下示例排除com.example：module1，只有那个伪物：
<project>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<excludes>
<exclude>
<groupId>com.example</groupId>
<artifactId>module1</artifactId>
</exclude>
</excludes>
</configuration>
</plugin>
</plugins>
</build>
</project>此示例排除了属于com.example群：
<project>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<excludeGroupIds>com.example</excludeGroupIds>
</configuration>
</plugin>
</plugins>
</build>
</project>JAR工具
当制造层叠罐或战争时，Spring-boot-jarmode-toolsjar 会作为依赖添加到你的档案中。
有了这个 jar 在类路径上，你可以以特殊模式启动应用，允许引导代码运行与应用完全不同的程序，比如提取层的程序。
如果你想排除这种依赖，可以通过以下方式实现：
<project>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<includeTools>false</includeTools>
</configuration>
</plugin>
</plugins>
</build>
</project>自定义图层配置
默认设置是将依赖分为快照和非快照，但你可能会有更复杂的规则。
例如，你可能想在专用层中隔离公司特定的项目依赖。
如下layers.xml配置示例为其中一个配置：
<layers xmlns="http://www.springframework.org/schema/boot/layers"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/boot/layers
https://www.springframework.org/schema/boot/layers/layers-3.3.xsd">
<application>
<into layer="spring-boot-loader">
<include>org/springframework/boot/loader/**</include>
</into>
<into layer="application" />
</application>
<dependencies>
<into layer="snapshot-dependencies">
<include>*:*:*SNAPSHOT</include>
</into>
<into layer="company-dependencies">
<include>com.acme:*</include>
</into>
<into layer="dependencies"/>
</dependencies>
<layerOrder>
<layer>dependencies</layer>
<layer>spring-boot-loader</layer>
<layer>snapshot-dependencies</layer>
<layer>company-dependencies</layer>
<layer>application</layer>
</layerOrder>
</layers>上述配置产生了额外的公司依赖关系与所有库叠加com.acme组ID。