Ускорение Maven сборки

А если кратко, то запускайте Maven Daemon.

Планируется еще Incremental Build (подробнее в cache.md)

Если вкратце, то после сборки результат сохраняется в общий кеш, который можно использовать как на CI, так и локально. Если у вас большой проект, то пересобираться будут только ваши изменения.

Как я однажды неожиданно ускорил сборку мавеном на Google Cloud Build: изначально использовался образ из докер хаба. Но иногда сборка падала с ошибкой "Connection reset" от central репозитория. Так как проект содержит в основном Spring Boot микросервисы, то был сделан образ на основе официального после прогона

RUN mvn dependency:resolve compiler:help resources:help jar:help surefire:help help:help

Образ пересобирается при переходе на новую версию Spring Boot. По итогу сборка образа микросервиса с тестами занимает в районе минуты.

Могу добавить еще пару советов:

1) Довольно очевидная вещь, но многие почему-то пренебрегают. Обновляйте maven! Он развивается не такими быстрыми темпами как gradle (может это и хорошо), но почти в каждой версии есть улучшения производительности.

На большом проекте версия 3.6.3 заметно быстрее, чем 3.6.0, а 3.8.3 - еще быстре

2) Иногда использовать --offline может быть неудобно, когда нет уверенности что нужные артефакты уже скачаны в локальный репозиторий. Но есть замечательный ключ --nsu (no snapshot update) который позволит скачать недостающие артефакты и не полезет за обновление снепшотов

3) Еще немного можно выиграть если отключить раскраску вывода (ключ -B или --batch-mode)

4) Также ускорение сборки за счет оптимизации вывода в консоль можно получить используя takari concurrent-build-logger (GitHub - takari/concurrent-build-logger: Better Maven multithreaded build logging) .

Но ускорение - это только приятный побочный эффект. На самом деле плагин решает проблему "перемешивания" вывода при параллельной сборке, так что это настоящий must have.

В отличие от других плагинов от такари он не требует переделок и тонкой настройки сборки.

5) Эффективность параллельной сборки очень сильно зависит от того, как у вас устроены зависимости между модулями. Если какой-то модуль нужен для сборки остальных, то его сборка превратиться в бутылочное горлышко.

Один из частных приемов, которые можно использовать в данном случае - вынести тесты этого модуля в отдельный модуль, чтобы, как только будет завершена компиляция, maven мог начать заниматься зависимыми модулями.

6) И, напоследок, совет, который по эффективности бывает сравним с включением maven daemon и использование параллельной сборки. Если вы пользуетесь антивирусом, то настройте в нем исключения для

• Процесса Java

• Папки JDK

• Папки с исходниками

• Папки локального репозитория maven

При сборке на Дженкинсе и локально немного помогает свойство --no-transfer-progress, отключающее вывод сообщение о загрузке зависимостей и уменьшающее объём логов.

Что касается распараллеливания, то, ИМХО, предпочтительнее делать это с помощью JUnit 5, из коробки поддерживающего параллелизм. Нужно добавить в `test/resources` файл junit-platform.properties

junit.jupiter.execution.parallel.enabled = true
junit.jupiter.execution.parallel.mode.default = same_thread
junit.jupiter.execution.parallel.mode.classes.default = concurrent

Если тесты мешают друг другу, то они группируются в наборы с помощью подобного кода:

@RunWith(JUnitPlatform.class)
@SelectClasses({

})
public class SystemTestSuite {

}