Spring Boot Maven Plugin — repackage target; executable configuration of spring-boot-maven-plugin

Spring Boot Maven Plugin – repackage target

The Spring Boot Maven Plugin plug-in provides spring boot support in maven. Allows you to package a runnable jar or war package.

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 replacement
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>
twenty one       ...
22 </plugins>
twenty three     ...
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 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>
twenty one     ...
22 </plugins>
twenty three   ...
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: The layout of a regular executable jar package.
WAR: The layout of the executable war package.
ZIP (same as DIR): Same as the jar package layout using PropertiesLauncher.
MODULE: includes dependent packages (excluding dependent packages with scope provided) and project resources
NONE: Includes all dependent packages and project resources.

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>
twenty one         ...
22 </plugin>
twenty three       ...
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 formed by 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: Adding repackage to the pom will create an executable package. MANIFEST.MF has a startup class, but the executable package cannot be introduced as a dependency. When introducing such a jar, 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 the pom file is found in the outer pom,
5: 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.