Ответ
Результат сборки Java-проекта — это готовые к использованию артефакты, тип которых определяется конфигурацией проекта (обычное приложение, веб-приложение, библиотека).
Типичные результаты в зависимости от проекта:
| Тип проекта | Основной артефакт | Расположение (Maven/Gradle) |
|---|---|---|
| Библиотека / Обычное приложение | JAR-файл | target/*.jar / build/libs/*.jar |
| Веб-приложение | WAR-файл | target/*.war / build/libs/*.war |
| Spring Boot приложение | Исполняемый (fat) JAR | target/*.jar / build/libs/*.jar |
| Модуль (без упаковки) | Каталог с .class файлами |
target/classes / build/classes/java/main |
Что включает в себя процесс сборки (build lifecycle):
- Компиляция исходного кода →
.classфайлы. - Копирование ресурсов (конфиги, свойства).
- Выполнение тестов (опционально, но рекомендуется).
- Упаковка (packaging) → создание JAR/WAR архива.
- Для fat JAR: объединение всех зависимостей в один архив.
Пример конечной структуры для Maven-проекта Spring Boot:
target/
├── my-boot-app-0.0.1-SNAPSHOT.jar # Fat JAR (можно запустить java -jar)
├── classes/
│ └── ... # .class файлы
└── test-classes/
└── ... # .class файлы тестовОтвет 18+ 🔞
А, ну вот, смотри, объясняю как есть, без этих ваших заумных мануалов. Результат сборки — это, грубо говоря, то, что у тебя в итоге получается в руках, когда ты закончил этот цирк с конями под названием mvn clean install или gradle build.
Что там вылезает на свет божий, в зависимости от того, что ты строил:
| Что ты делал | Что получишь в итоге | Где обычно валяется (Maven/Gradle) |
|---|---|---|
| Библиотека или просто приложение | Обычный JAR-файл, который сам по себе нихуя не запустится | target/*.jar / build/libs/*.jar |
| Веб-приложение (для какого-нибудь Tomcat'а) | WAR-файл, этакий архив для сервлет-контейнера | target/*.war / build/libs/*.war |
| Spring Boot приложение (модно, молодёжно) | Толстый, жирный, исполняемый JAR (fat JAR). В нём всё, включая кухонную раковину. Запускается просто java -jar. |
target/*.jar / build/libs/*.jar |
| Просто модуль, который ты не упаковывал | Папка с кучей скомпилированных .class файлов. Без архива, так, сырьё. |
target/classes / build/classes/java/main |
А теперь, блядь, как это всё происходит, по шагам (build lifecycle, ёпта):
- Компиляция. Твой красивый исходник на Java превращается в эти самые
.classфайлы — байт-код, который понимает JVM. - Копирование ресурсов. Все эти твои
application.properties, XML'ки, картинки с котиками — переносятся куда надо. - Запуск тестов. Вот тут-то часто и начинается пиздец. Если, конечно, ты их писал. А если нет — ну и хуй с ним, пропускаем.
- Упаковка (packaging). Всё это добро запихивается в архив — JAR или WAR.
- Для жирного Spring Boot JAR'а: происходит магия. Все зависимости, которые ты подключал, засасываются внутрь этого одного файла. Получается монструозная бандура, но зато самодостаточная.
Вот, смотри, как выглядит папка target у типичного Spring Boot проекта после сборки, чтобы ты представлял:
target/
├── my-boot-app-0.0.1-SNAPSHOT.jar # Вот он, красавец, fat JAR. Запускай и радуйся.
├── classes/ # А это распакованное нутро — твои классы.
│ └── ... # куча .class файлов
└── test-classes/ # Классы из тестов, если они были.
└── ...Вот и вся магия. Собрал, получил артефакт, запустил или задеплоил. Главное — чтобы на шаге с тестами всё не накрылось медным тазом.