Какими инструментами сборки пользуются в Java

Что проверяют

Понимаете ли вы разницу в подходах, а не только названия. Следом обычно просят сравнить Maven и Gradle и объяснить, что вы выбрали бы для нового проекта и почему.

Как отвечать

Основных инструмента два, остальные нишевые:

• Maven: декларативная модель и соглашения вместо настройки. Структура src/main/java и src/test/java, фиксированный жизненный цикл (validate, compile, test, package, verify, install, deploy), плагины привязаны к фазам. Зависимости из Maven Central кэшируются в ~/.m2, области видимости compile, provided, runtime, test. Любой проект на Maven читается одинаково;
• Gradle: граф задач, скрипты на Kotlin DSL (по умолчанию для новых проектов) или Groovy. Быстрее за счёт инкрементальной сборки, build cache и демона, лучше подходит для больших многомодульных проектов и Android. Конфигурации implementation и api из плагина java-library определяют, какие зависимости видны потребителям модуля;
• Ant: исторический инструмент с императивными XML-задачами, управление зависимостями только через Ivy. Сегодня встречается в legacy;
• Bazel: большие монорепозитории с воспроизводимой сборкой на нескольких языках.

Для нового проекта разумный ответ такой: Maven, если нужна простота и команда его знает, Gradle, если модулей много и важна скорость сборки. У обоих есть wrapper (mvnw, gradlew), собирать стоит через него, чтобы версия сборщика была закреплена в репозитории. Для Maven есть ещё mvnd, демон, который ускоряет повторные сборки.

Где спотыкаются

Называют Spring Boot инструментом сборки. Он лишь даёт плагины для Maven и Gradle, которые упаковывают приложение в исполняемый jar.

Утверждают, что Gradle всегда быстрее. На маленьком проекте разницы не видно, а скрипт с тяжёлой логикой на этапе конфигурации замедляет каждую сборку.

Приводят примеры с конфигурацией compile в Gradle. Её удалили в Gradle 7, старые скрипты с ней не соберутся, вместо неё implementation или api.