Разница между spring-boot: repackage и пакетом Maven

1. Обзор

Apache Maven — это широко используемый инструмент управления зависимостями проектов и инструмент построения проектов.

За последние несколько лет Spring Boot стал довольно популярным фреймворком для создания приложений. Существует также подключаемый модуль Spring Boot Maven , обеспечивающий поддержку Spring Boot в Apache Maven.

Мы знаем, что когда мы хотим упаковать наше приложение в артефакт JAR или WAR с помощью Maven, мы можем использовать mvn package . Тем не менее, плагин Spring Boot Maven поставляется с целью переупаковки , и он также вызывается в команде mvn .

Иногда две команды mvn сбивают с толку. В этом уроке мы обсудим разницу между mvn package и spring-boot:repackage .

2. Пример приложения Spring Boot

Прежде всего, мы создадим простое приложение Spring Boot в качестве примера:

@SpringBootApplication
public class DemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

Чтобы убедиться, что наше приложение запущено и работает, давайте создадим простую конечную точку REST:

@RestController
public class DemoRestController {
    @GetMapping(value = "/welcome")
    public ResponseEntity welcomeEndpoint() {
        return ResponseEntity.ok("Welcome to ForEach Spring Boot Demo!");
    }
}

3. Пакет Maven Цель

Нам нужна только зависимость spring-boot-starter-web для сборки нашего приложения Spring Boot:

<artifactId>spring-boot-artifacts-2</artifactId>
<packaging>jar</packaging>
...
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
...

Целью пакета Maven будет взять скомпилированный код и упаковать его в распространяемый формат , который в данном случае является форматом JAR:

$ mvn package
[INFO] Scanning for projects...
[INFO] ------< com.foreach.spring-boot-modules:spring-boot-artifacts-2 >------
[INFO] Building spring-boot-artifacts-2 1.0.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
 ... 
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ spring-boot-artifacts-2 ---
[INFO] Building jar: /home/kent ... /target/spring-boot-artifacts-2.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
 ...

После выполнения команды mvn package мы можем найти встроенный JAR-файл spring-boot-artifacts-2.jar в целевом каталоге. Давайте проверим содержимое созданного файла JAR :

$ jar tf target/spring-boot-artifacts-2.jar
META-INF/
META-INF/MANIFEST.MF
com/
com/foreach/
com/foreach/demo/
application.yml
com/foreach/demo/DemoApplication.class
com/foreach/demo/DemoRestController.class
META-INF/maven/...

Как видно из приведенного выше вывода, файл JAR, созданный командой mvn package, содержит только ресурсы и скомпилированные классы Java из исходников нашего проекта .

Мы можем использовать этот JAR-файл как зависимость в другом проекте. Однако мы не можем выполнить файл JAR с помощью java -jar JAR_FILE, даже если это приложение Spring Boot. Это связано с тем, что зависимости времени выполнения не связаны. Например, у нас нет контейнера сервлетов для запуска веб-контекста.

Чтобы запустить наше приложение Spring Boot с помощью простой команды java -jar , нам нужно создать толстый JAR . В этом нам может помочь плагин Spring Boot Maven.

4. Цель переупаковки плагина Spring Boot Maven

Теперь давайте разберемся, что делает spring-boot:repackage .

4.1. Добавление плагина Spring Boot Maven

Чтобы выполнить цель переупаковки , нам нужно добавить плагин Spring Boot Maven в наш pom.xml :

<build>
    <finalName>${project.artifactId}</finalName>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

4.2. Выполнение команды spring-boot: repackage

Теперь давайте очистим ранее созданный JAR-файл и попробуем spring-boot:repackage :

$ mvn clean spring-boot:repackage     
 ...
[INFO] --- spring-boot-maven-plugin:2.3.3.RELEASE:repackage (default-cli) @ spring-boot-artifacts-2 ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
...
[ERROR] Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:2.3.3.RELEASE:repackage (default-cli) 
on project spring-boot-artifacts-2: Execution default-cli of goal 
org.springframework.boot:spring-boot-maven-plugin:2.3.3.RELEASE:repackage failed: Source file must not be null -> [Help 1]
...

Упс, это не работает. Это связано с тем, что цель spring-boot:repackage берет существующий архив JAR или WAR в качестве источника и переупаковывает все зависимости времени выполнения проекта внутри окончательного артефакта вместе с классами проекта. Таким образом, переупакованный артефакт становится исполняемым с помощью командной строки java -jar JAR_FILE.jar .

Поэтому нам нужно сначала собрать файл JAR перед выполнением цели spring-boot:repackage :

$ mvn clean package spring-boot:repackage
 ...
[INFO] Building spring-boot-artifacts-2 1.0.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
 ...
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ spring-boot-artifacts-2 ---
[INFO] Building jar: /home/kent/.../target/spring-boot-artifacts-2.jar
[INFO] 
[INFO] --- spring-boot-maven-plugin:2.3.3.RELEASE:repackage (default-cli) @ spring-boot-artifacts-2 ---
[INFO] Replacing main artifact with repackaged archive
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
 ...

4.3. Содержимое переупакованного JAR-файла

Теперь, если мы проверим целевой каталог, мы увидим переупакованный файл JAR и исходный файл JAR:

$ ls -1 target/*jar*
target/spring-boot-artifacts-2.jar
target/spring-boot-artifacts-2.jar.original

Давайте проверим содержимое перепакованного JAR-файла:

$ jar tf target/spring-boot-artifacts-2.jar 
META-INF/
META-INF/MANIFEST.MF
 ...
org/springframework/boot/loader/JarLauncher.class
 ...
BOOT-INF/classes/com/foreach/demo/
BOOT-INF/classes/application.yml
BOOT-INF/classes/com/foreach/demo/DemoApplication.class
BOOT-INF/classes/com/foreach/demo/DemoRestController.class
META-INF/maven/com.foreach.spring-boot-modules/spring-boot-artifacts-2/pom.xml
META-INF/maven/com.foreach.spring-boot-modules/spring-boot-artifacts-2/pom.properties
BOOT-INF/lib/
BOOT-INF/lib/spring-boot-starter-web-2.3.3.RELEASE.jar
...
BOOT-INF/lib/spring-boot-starter-tomcat-2.3.3.RELEASE.jar
BOOT-INF/lib/tomcat-embed-core-9.0.37.jar
BOOT-INF/lib/jakarta.el-3.0.3.jar
BOOT-INF/lib/tomcat-embed-websocket-9.0.37.jar
BOOT-INF/lib/spring-web-5.2.8.RELEASE.jar
...
BOOT-INF/lib/httpclient-4.5.12.jar
...

Если мы проверим вывод выше, он намного длиннее, чем файл JAR, созданный командой mvn package .

Здесь, в перепакованном JAR-файле, у нас есть не только скомпилированные классы Java из нашего проекта, но и все библиотеки времени выполнения, которые нужны для запуска нашего приложения Spring Boot . Например, встроенная библиотека tomcat упакована в каталог BOOT-INF/lib .

Далее запустим наше приложение и проверим, работает ли оно:

$ java -jar target/spring-boot-artifacts-2.jar 
  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/

2020-12-22 23:36:32.704  INFO 115154 [main] com.foreach.demo.DemoApplication      : Starting DemoApplication on YK-Arch with PID 11515...
...
2020-12-22 23:36:34.070  INFO 115154 [main] o.s.b.w.embedded.tomcat.TomcatWebServer: Tomcat started on port(s): 8080 (http) ...
2020-12-22 23:36:34.078  INFO 115154 [main] com.foreach.demo.DemoApplication      : Started DemoApplication in 1.766 seconds ...

Наше приложение Spring Boot запущено и работает. Теперь давайте проверим это, вызвав нашу конечную точку /welcome :

$ curl http://localhost:8080/welcome
Welcome to ForEach Spring Boot Demo!

Большой! Получили ожидаемый ответ. Наше приложение работает правильно.

4.4. Выполнение цели spring-boot:repackage во время жизненного цикла пакета Maven

Мы можем настроить подключаемый модуль Spring Boot Maven в нашем pom.xml для переупаковки артефакта на этапе упаковки жизненного цикла Maven. Другими словами, когда мы запускаем пакет mvn, spring -boot:repackage будет выполняться автоматически.

Конфигурация довольно проста. Мы просто добавляем цель переупаковки в исполнительный элемент:

<build>
    <finalName>${project.artifactId}</finalName>
    <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 clean package :

$ mvn clean package
 ...
[INFO] Building spring-boot-artifacts-2 1.0.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
...
[INFO] --- spring-boot-maven-plugin:2.3.3.RELEASE:repackage (default) @ spring-boot-artifacts-2 ---
[INFO] Replacing main artifact with repackaged archive
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
 ...

Вывод показывает, что цель переупаковки была выполнена. Если мы проверим файловую систему, мы обнаружим, что переупакованный файл JAR создан:

$ ls -lh target/*jar*
-rw-r--r-- 1 kent kent  29M Dec 22 23:56 target/spring-boot-artifacts-2.jar
-rw-r--r-- 1 kent kent 3.6K Dec 22 23:56 target/spring-boot-artifacts-2.jar.original

5. Вывод

В этой статье мы обсудили разницу между mvn package и spring-boot:repackage .

Кроме того, мы узнали, как выполнять spring-boot:repackage на этапе пакета жизненного цикла Maven.

Как всегда, весь код в этой статье доступен на GitHub .