Comments 4
Проводили сравнение по скорости Gradle Cache (Develocity) и Maven Cache?
И насчет того что Maven Cache "в целом неплохо работает для проектов среднего размера", есть пример проекта большого размера где бы он плохо работал?
Проводили сравнение по скорости Gradle Cache (Develocity) и Maven Cache?
Нет, но предположу что для билда, где все таски берутся из кеша результат будет примерно одинаковый.
есть пример проекта большого размера где бы он плохо работал?
Здесь я еще раз заострю внимание на том, что дело по сути не в размере, а в том что проект большего размера с большей вероятностью будет иметь кастомизацию. Отвечая на вопрос - да, есть пример такого проекта. Там из-за большого количества интеграционные тесты были разделены на группы и выполнялись в отдельных джобах. При этом компилировалось всё один раз на первом шаге (mvn clean package -DskipTests=true), и передавалось на следующий этап в параллельные пайплайны (mvn failsafe:integration-test failsafe:verify -Dit.test=$TEST_FILTER_1 где TEST_FILTER_1 - N разных фильтров тестов), так экономили на компиляции. С apache build cache возникло несколько проблем:
он работает только с циклами lifecycle, а не goal. Т.е. указывать goal нельзя
failsafe:integration-test, можно например так:mvn verify, но тогда Maven будет прогонять все шаги включая компиляцию (в теории ее наверно можно отключить через skip compile plugin; но это не единственная проблема)оказалось достаточно проблематично подобрать такую конфигурацию extension, чтобы всё правильно кешировалось. Т.е. легко допустить ошибку, при которой кешируется пустой результат запуска тестов и потом ошибочно берется из кеша даже при других параметрах
Думаю, в целом можно настроить extension, поэтому я и рекомендовал его посмотреть. В нашем случае пока разбирались в коде apache build cache extension (который весьма компактный проект), написали свой собственный, т.к. в любом случае нужны были доработки вроде дополнительной мета-информации, сбор метрик и пр.
Можете поделиться своими наработками?
Может стоит их отправить в Apache?
Maven Cache еще долго бы без посторонней помощи разрабатывали, хотя после Gradle Cache идея очевидная.
Плагины с поддержкой кеширования: https://github.com/seregamorph/maven-surefire-cached
Прототип переписанного планировщика с улучшенным параллелизмом: https://github.com/seregamorph/maven-surefire-cached/pull/3 - это изменение по сути подразумевает слом обратной совместимости из-за очередности фаз сборки
По поводу поделиться с Apache - мне не жалко (код выше под лицензией Apache 2.0). Только нет уверенности, что это попадает в их планы. Я смотрел несколько видео и читал статьи от мейнтейнеров проекта и насколько понял, они очень сильно заморочены на обратную совместимость. С одной стороны это хорошо, с другой - это существенно ограничивает потенциальное развитие проекта. В конце концов, Maven - это инструмент, а не язык программирования, поэтому ломающие изменения здесь могли бы быть ок (а иначе зачем обновляться?). Для сравнения Gradle регулярно ломает совместимость своих API, но делают они это весьма аккуратно, заблаговременно объявляя API устаревшими, давая понятную диагностику и пр. И их инструмент активно развивается.
При возможности думаю поделиться своими идеями с мейнтейнерами Maven (либо письмом, либо где-нибудь на конференции).
Как ускорить Maven сборку без переезда на Gradle