Spring Boot Maven Plugin – repackage target
The Spring Boot Maven Plugin plug-in provides spring boot support in maven. Allows you to package executable jar packages or war packages.
The plugin provides several maven goals to work with Spring Boot applications. In total there are:
spring-boot:repackage
spring-boot:run
spring-boot:start and spring-boot:stop
spring-boot:build-info
repackage: Create an automatically executable jar or war file. It can replace a regular artifact, or be attached to the maven build lifecycle with a separate classifier.
Let's take a closer look at the repackage goal.
1. Simple quotation
To repackage the application, we need to add a simple reference to the Spring Boot Maven Plugin in the pom.xml file. The code is as follows: The simplest structure of repaceage
1 <build>
2 ...
3 <plugins>
4 ...
5 <plugin>
6 <groupId>org.springframework.boot</groupId>
7 <artifactId>spring-boot-maven-plugin</artifactId>
8 <version>1.5.7.RELEASE</version>
9 <executions>
10 <execution>
11 <goals>
12 <goal>repackage</goal>
13 </goals>
14 </execution>
15 </executions>
16 </plugin>
17 ...
18 </plugins>
19 ...
20 </build>
The simplest structure of respaceage
2. Eliminate unnecessary dependencies
This example repackages a jar or war package that is built in the package phase of the maven life cycle, including any dependencies defined in the project (including scope provided). If there are some dependent modules that need to be excluded, you can use an exclude option.
By default, the two maven goals repackage and run will include any dependencies defined in the project. Some dependencies are required to be excluded from the executable jar. There are three ways to exclude dependent modules when the package is run.
Method 1: Exclude a specific maven module through a unique combination of groupId and artifactId. (If necessary, classifier can be added to uniquely confirm.)
1 <project>
2 ...
3 <build>
4 ...
5 <plugins>
6 ...
7 <plugin>
8 <groupId>org.springframework.boot</groupId>
9 <artifactId>spring-boot-maven-plugin</artifactId>
10 <version>1.5.6.RELEASE</version>
11 <configuration>
12 <excludes>
13 <exclude>
14 <groupId>com.foo</groupId>
15 <artifactId>bar</artifactId>
16 </exclude>
17 </excludes>
18 </configuration>
19 ...
20 </plugin>
21 ...
22 </plugins>
23 ...
24 </build>
25 ...
26 </project>
Exclude a specific maven module
Method 2: Exclude all maven modules that match the "specified artifactId".
1 <project>
2 ...
3 <build>
4 ...
5 <plugins>
6 ...
7 <plugin>
8 <groupId>org.springframework.boot</groupId>
9 <artifactId>spring-boot-maven-plugin</artifactId>
10 <version>1.5.6.RELEASE</version>
11 <configuration>
12 <excludeArtifactIds>my-lib,another-lib</excludeArtifactIds>
13 </configuration>
14 ...
15 </plugin>
16 ...
17 </plugins>
18 ...
19 </build>
20 ...
21 </project>
Exclude all maven modules for the project with the specified artifactId
Method 3: Exclude all maven modules belonging to the "specified groupId".
1 <project>
2 ...
3 <build>
4 ...
5 <plugins>
6 ...
7 <plugin>
8 <groupId>org.springframework.boot</groupId>
9 <artifactId>spring-boot-maven-plugin</artifactId>
10 <version>1.5.6.RELEASE</version>
11 <configuration>
12 <excludeGroupIds>com.foo</excludeGroupIds>
13 </configuration>
14 ...
15 </plugin>
16 ...
17 </plugins>
18 ...
19 </build>
20 ...
21 </project>
Exclude all maven modules belonging to the specified groupId
3. Rewrite the manifest
This plug-in can also rewrite the project manifest (MANIFEST.MF of the executable jar package), especially the management of the Main-Class and Start-Class startup classes. If the default configuration cannot meet the needs, we can configure it here. Main-Class can be truly controlled through the plugin's layout attribute.
1 <build>
2 ...
3 <plugins>
4 ...
5 <plugin>
6 <groupId>org.springframework.boot</groupId>
7 <artifactId>spring-boot-maven-plugin</artifactId>
8 <version>1.5.7.RELEASE</version>
9 <configuration>
10 <mainClass>${start-class}</mainClass>
11 <layout>ZIP</layout>
12 </configuration>
13 <executions>
14 <execution>
15 <goals>
16 <goal>repackage</goal>
17 </goals>
18 </execution>
19 </executions>
20 </plugin>
21 ...
22 </plugins>
23 ...
24 </build>
repackage mainClass
Execute the packaging command: mvn package spring-boot:repackage. Note: mvn spring-boot:repackage cannot be written here. Otherwise, a Source must refer to an existing file exception will be reported.
The layout attribute defaults to the archive type (jar or war). There are 5 types in total:
JAR：常规的可执行jar包的布局。
WAR：可执行war包的布局。
ZIP（和DIR一样）：和使用PropertiesLauncher的jar包布局一样。
MODULE:包括依赖包（排除scope为provided的依赖包）和项目资源
NONE:包括所有的依赖包和项目资源。
4. Use classifier to separate code packages and dependency packages
When you write a project yourself and need to publish it for others to rely on, you only need to package the code you wrote, and the dependent packages cannot be imported. Otherwise, when someone else uses the package you provided, there will be duplicate packages, resulting in a very huge package when packaged.
Under the Spring Boot Maven Plugin, we only need to provide a classifier to achieve this function. details as follows:
1 <project>
2 ...
3 <build>
4 ...
5 <plugins>
6 ...
7 <plugin>
8 <groupId>org.springframework.boot</groupId>
9 <artifactId>spring-boot-maven-plugin</artifactId>
10 <version>1.5.7.RELEASE</version>
11 <executions>
12 <execution>
13 <goals>
14 <goal>repackage</goal>
15 </goals>
16 <configuration>
17 <classifier>exec</classifier>
18 </configuration>
19 </execution>
20 </executions>
21 ...
22 </plugin>
23 ...
24 </plugins>
25 ...
26 </build>
27 ...
28 </project>
The repackage (goal) of the spring-boot-maven plug-in has the following two functions:
1. Repackage the jar package based on the original Maven package. The newly formed jar package not only contains application class files and configuration files, but also contains jar packages that the application depends on and Springboot startup related classes (loader, etc.) , to meet the characteristics of Springboot independent application;
2. Rename the original Maven packaged jar to XXX.jar.original as the original file;
Package plugin pom:
<build>
<finalName>${project.artifactId}</finalName>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>2.6.7</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
<resources>
<resource>
<directory>src/main/resources</directory>
</resource>
<resource>
<directory>src/main/java</directory>
<includes>
<include>**/*.xml</include>
</includes>
<filtering>false</filtering>
</resource>
</resources>
</build>
Note:
1: The repackage added to the pom is an executable package. MANIFEST.MF has a startup class, but the executable package cannot be introduced as a dependency. If such a jar is introduced, an error will be reported that the class cannot be found. Error: com.oceansite.system.config.ShipImoConfig
2: The dependency package without repackage in the pom is non-executable. There is no startup class in MANIFEST.MF, but it can be introduced into other projects as a dependent jar package.
3: The packaged plug-in version should be consistent with the springboot version, otherwise a version error will be reported. If the submodule introduces other modules. Direct sub-module packaging will report an error that the dependency cannot be found (because it will be found from the warehouse), and the entire project needs to be packaged together to successfully package it.
4: If you rely on the cloud project, you only need to add the packaging plug-in to the pom file of the corresponding module, such as: file, which is not needed under the models module (file is a sub-module under the models module), because it only plays a role The role of folders. Moreover, the pom file takes effect from the inside out. If the pom under this module is not introduced, and look for
5 in the outer pom: If you forcibly add repackage to the pom file of a public package without a main class, an error will be reported during packaging: Unable to find main class
executable configuration of spring-boot-maven-plugin
Set this configuration to true, and the packaged jar/war will be executable.
The fully executable jar/war embeds an additional script in front of the file, which causes some commands to fail to execute, such as jar -xf, etc.