Этап 5 - Plugins: расширение возможностей сборки

Инструмент сборки не может заранее знать каждую возможную задачу. Проектам нужны compilation, тесты, integration тесты, shading, Spring Boot упаковка, code generation, publishing, Docker images и quality checks.

Плагин - это расширение, который добавляет goals, задачи, conventions или упаковка behavior в сборка. Build tools остаются небольшими в ядре и расширяются через плагины.

Какую проблему это решает

Maven плагины предоставляют goals. Compiler плагин компилирует Java. Surefire запускает unit тесты. Failsafe запускает integration тесты. Jar, war и shade плагины создают разные формы артефакты.

Plugin настройка определяет поведение плагин: Java релиз, тест include patterns, main class, сгенерированный source directory или упаковку зависимости в fat JAR.

Execution связывает плагин goal с жизненный цикл phase. Например, integration-тест goal может запускаться в phase integration-тест, а проверка результата - в verify.

Gradle плагины добавляют задачи и conventions. Plugin java добавляет compileJava, тест и jar. Spring Boot плагин добавляет bootJar, зависимость management integration и приложение упаковка behavior.

Custom плагины нужны, когда сборка logic переиспользуется во многих проектах. Команда может создать плагин, который применяет code style, тестing defaults, publishing rules и company репозиторий settings.

Последовательность шагов

1. сборка tool.
2. плагин.
3. настройка.
4. execution.
5. сгенерированный result.

Эта последовательность - картинка в голове, с которой нужно читать файлы сборки. Названия в Maven и Gradle отличаются, но практический вопрос одинаковый: какой входные данные используется, какая задача запускается, какой результат получается и где этот результат хранится.

Конкретный пример

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <настройка>
    <релиз>17</релиз>
  </настройка>
</plugin>

Полезная таблица

Где это встречается в работе

Когда сборка делает что-то неожиданное, сначала смотри плагин настройка. Большая часть сборка behavior - не магия, а плагины и их executions.

В командной разработке знание сборки - не необязательная теория. Оно влияет на локальный development, время CI, зависимость upgrades, стабильность релиз и debugging. Когда Spring сервис не стартует после изменения зависимость, CI скачивает другую библиотека версия или артефакт не получается deployed, ответ обычно находится в сборка настройка, зависимость graph, упаковка step или репозиторий setup.

Частые ошибки

• Копировать настройка, не понимая, на какой слой сборка она влияет.
• Считать локально успешный сборка доказательством, что CI и production delivery тоже сработают.
• Игнорировать зависимость trees, сгенерированный результат и репозиторий rules до момента failed релиз.
• Смешивать приложение запуск приложения настройка и сборка-time настройка.

Чеклист понимания

• Я могу объяснить главные terms этой статьи, не перечитывая сборка file вслух.
• Я могу нарисовать последовательность от исходный код до артефакт для этой темы.
• Я могу назвать command или file, который первым проверю при сборка problem.

Вопросы для самопроверки

1. Какую проблему этот сборка concept решает в реальном Java или Spring проект?
2. Какой file или command быстрее всего даст evidence, когда что-то ломается?
3. Какая ошибка заставит сборка работать локально, но падать в CI или у другого разработчик?

Практика перед следующим уроком

Откройте Maven или Gradle проект и найдите плагин или задачу, отвечающую за тесты. Запишите, когда она запускается, какая команда ее вызывает и какой отчет доказывает, что тесты действительно выполнились.