Comments 7
А если кратко, то запускайте Maven Daemon.
Планируется еще Incremental Build (подробнее в cache.md)
Если вкратце, то после сборки результат сохраняется в общий кеш, который можно использовать как на CI, так и локально. Если у вас большой проект, то пересобираться будут только ваши изменения.
Подскажите, а CACHE-REMOTE уже в stable или нет? Пока вижу что дока не в главном репозитории, https://github.com/deutschebank/maven/blob/7d1b8c094f2145909978142a0faa4257a244dc22/Documentation/CACHE-REMOTE.md
И еще вопрос. Gradle может искать артефакт в разных репозиториях. Например, maven central репозиторий внутри DMZ не доступен, но доступен Nexus Sonatype, он скачает с Nexus Sonatype. Планируется такое в Maven?
К сожалению, не все плагины это поддерживают. А трудозатраты на то, чтобы сделать плагин поддерживающим, могут быть достаточно высоки.
Как я однажды неожиданно ускорил сборку мавеном на 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 {
}
Ускорение Maven сборки