Этап 8 - Packaging: создание JAR и WAR приложений
Компиляция создает .class-файлы, но для развертывания нужен готовый артефакт. Packaging определяет, какой файл будет создан и как запуск приложения его запустит.
Упаковка - это шаг, который превращает скомпилированный код и ресурсы в архив: JAR, WAR или исторически EAR. Для современных Spring Boot сервисы чаще всего результатом является executable JAR.
Какую проблему это решает
JAR - ZIP-like архив с classes, resources и metadata. Manifest может задавать Main-Class, classpath details и другую metadata. Обычный thin JAR может требовать external зависимости в classpath.
WAR предназначен для deployment в servlet container. У него структура с WEB-INF, classes, библиотеки и web resources. Старые enterprise deployments часто использовали WAR files, развернутые во внешний Tomcat или приложение server.
EAR - enterprise архив для упаковки нескольких Java EE модули вместе. Современный Spring Boot backend редко начинается с EAR, но термин полезно узнавать в legacy systems.
Fat JAR включает приложение code и зависимости в один архив. Thin JAR содержит в основном приложение code и ожидает зависимости снаружи. Spring Boot executable JAR имеет специальную layout и launcher, чтобы работало java -jar app.jar.
Выбирай JAR для большинства standalone Spring Boot сервисы и containerized deployments. Выбирай WAR, если организация требует deployment в существующий servlet container.
Последовательность шагов
- compiled classes.
- resources.
- manifest.
- jar/war.
- запуск приложения.
Эта последовательность - картинка в голове, с которой нужно читать файлы сборки. Названия в Maven и Gradle отличаются, но практический вопрос одинаковый: какой входные данные используется, какая задача запускается, какой результат получается и где этот результат хранится.
Конкретный пример
mvn package
java -jar target/orders-1.0.0.jar
./gradlew bootJar
java -jar сборка/libs/orders.jar
Полезная таблица
| Понятие | Значение |
|---|---|
| JAR | Обычный Java архив; часто для библиотеки и standalone apps. |
| Executable JAR | JAR, который запускается через java -jar. |
| WAR | Web архив для servlet containers. |
| EAR | Enterprise архив для legacy Java EE упаковка. |
| Fat JAR | Archive, включающий зависимости. |
| Thin JAR | Archive, ожидающий зависимости снаружи. |
Где это встречается в работе
Packaging - не косметический выбор. Он определяет, как приложение запускается, где живут зависимости и какая infrastructure нужна.
В командной разработке знание сборки - не необязательная теория. Оно влияет на локальный development, время CI, зависимость upgrades, стабильность релиз и debugging. Когда Spring сервис не стартует после изменения зависимость, CI скачивает другую библиотека версия или артефакт не получается deployed, ответ обычно находится в сборка настройка, зависимость graph, упаковка step или репозиторий setup.
Частые ошибки
- Копировать настройка, не понимая, на какой слой сборка она влияет.
- Считать локально успешный сборка доказательством, что CI и production delivery тоже сработают.
- Игнорировать зависимость trees, сгенерированный результат и репозиторий rules до момента failed релиз.
- Смешивать приложение запуск приложения настройка и сборка-time настройка.
Чеклист понимания
- Я могу объяснить главные terms этой статьи, не перечитывая сборка file вслух.
- Я могу нарисовать последовательность от исходный код до артефакт для этой темы.
- Я могу назвать command или file, который первым проверю при сборка problem.
Вопросы для самопроверки
- Какую проблему этот сборка concept решает в реальном Java или Spring проект?
- Какой file или command быстрее всего даст evidence, когда что-то ломается?
- Какая ошибка заставит сборка работать локально, но падать в CI или у другого разработчик?
Практика перед следующим уроком
Соберите JAR через Maven или Gradle и посмотрите папку с результатом. Найдите имя артефакта, расширение файла и команду, которой его можно запустить. Если файл не запускается, определите, какой настройки упаковки или плагина не хватает.