Ускоряем процесс сборки с maven

[IgorKamenev]

Может быть чуть больше текста стоит убрать под кат? ;)

[doom369]

Я убрал, но не работает

[javax]

Очень полезно. Спасибо.
А запуски юнит тестов оно не делает паралельными?

[doom369]

Делает, если тесты не зависят друг от друга и разнесены по модулям.

[jbaruch]

Если ничего не помогло, или если вы недовольны Maven-ом (как многие, очень многие), то вот вам радикальное решение — перепишите сборку на Gradle.
В плане скорости сборки у них есть совершенно убийственная фича — инктрементальная сборка. Идея состоит в том, что каждая задача определяет свои вводы и выводы (например для задачи javac это будут — исходники и бинарники соответственно). Перед запуском задачи Gradle проверяет вводы и выводы и если ни те, ни другие не изменились, задача не будет бежать вообще.

Ну и кроме того, у них, естественно, есть все, что есть в Maven-е, будь то многопоточное исполнение или исполняемый на фоне демон-процесс для ускорения инициализации.

[doom369]

Слышал, но не довелось пока попробовать. Кстати, Gradle интегрирован с ТeamCity?

[jbaruch]

На том же уровне, что и Maven.

[vdshat]

Какую версию Gradle используете? Мы гоняли 0.9, но из-за ошибок в кэшировании и, как раз, в инкрементарной сборке отказались.

[jbaruch]

нуууу, 0.9 это было так давно, что уже и неправда :-)

[monkegoist]

Я пробовал собирать один из рабочих проектов 3-й версией мавена, и не получил практически никакого прироста. Сборка в параллель будет хорошо работать только в том случае, если нет «тяжелых» модулей (как правильно указал автор). Если они есть, особого прироста тоже не будет (в моем случае, вместо 9 минут получилось 8). Еще один момент — не все последние версии плагинов в данный момент thread safe.

Раз уж речь в коментах зашла о TeamCity, то я обратил бы внимание на одну из ключевых возможностей, которые появились в 7-й версии — инкрементальную сборку. В этом случае TC с помощью собственных механизмов определяет модули, которые затронули закоммиченные изменения, и билдит только то, что нужно. Подробнее можно почитать здесь.

[ncuxez]

Статья ни о чем, можно было бы просто привести ссылку на выхлоп mvn --help с выделением следующего куска:

-T,--threads Thread count, for instance 2.0C where C is core multiplied

все.

И кстати, мавен тоже умеет не компилировать неизменившиеся сырцы.

[doom369]

>>И кстати, мавен тоже умеет не компилировать неизменившиеся сырцы.
Как?

[monkegoist]

Просто не делайте clean, и все.

[jbaruch]

да, был неправ, пример с сорцами дурацкий. javac сам умеет не компилировать не изменившиеся сорцы. А как на счет, например, не перепаковывать jar?

[korvindest]

JAR не надо перепаковывать, только если вы вообще ничего не поменяли. Я не уверен в том как эту ситуацию обработает Maven, но зачем вообще такое пытаться собрать?

[jbaruch]

Ну, Maven-же не знает, поменяли вы или нет. Вы поменяли что-то в каком-то модуле. Запускаете Maven в рутового проекта. Все, кроме javac, который сам знает, что ничего компилировать не нужно, будет бежать заново — генерация сорцов из дескрипторов, которые не поменялись (например), тесты на классы, которые не поменялись, запаковка в jar-ы файлов, которые не поменялись, и так далее.

[korvindest]

javac определяет неизменность исходника сравнивая время изменения исходника со временем создания .class Ни что на самом деле не мешает assembly плагину проверить время создания всех файлов участвующих в запаковке и ничего не делать если уже готовый архив новее.

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

[jbaruch]

Ну, тот факт, что ничто с технологической точки зрения не мешает Мавену сосать, не значит что он не сосет, увы и ах.
Грейдл лишь подтверждает тот факт, что система сборки может быть намого лучше и умнее, чем Мавен.

[korvindest]

То что вам больше нравится другой инструмент вовсе не означает того, что вам дано право оскорбительно отзываться о других инструментах, которые вполне успешно справляются со многими поставленными задачами.

2/3 мои проектов собираются Maven и я знаю в нем много достоинств и недостатков, однако при этом я не позволяю себе столь мерзких суждений в отношении других сборщиков, да и вообще инструментов, которые я использую.

Если вам что то не нравится, не пользуйтесь этим!

[jbaruch]

Напрасно вы так негодуете. Я использовал слово «сосет» не для обзывательств, а для описания отсутствия конкретной функциональности.
Грейдл, к сожалению, тоже во многом пока сосет, но счет в его пользу.

[doom369]

>>И кстати, мавен тоже умеет не компилировать неизменившиеся сырцы.
Как?

[zloddey]

Maven Shell не поможет на больших проектах. Проблема в баге maven compiler plugin, который приводит к утечке памяти в ClassLoader'е. Как результат, спустя несколько запусков mvnsh бодро валится с OutOfMemoryError.

Этот неприятный баг сильно нивелирует достоинства mvnsh. Нет особого смысла кешировать библиотеки, если спустя пару-другую сборок придётся перезапускать шелл. Особого выигрыша в скорости не возникает, не говоря уже о том, что сам процесс сборки становится менее предсказуемым и более нервным.

Наращивание места под PermGen лишь отсрочит проблему, но не решит её. Падения станут происходить чуть реже, но за счёт занятой памяти. Это не похоже на выгодную сделку…

[VaiMR]

В моем случае разбиение на модули хорошее, но сильно тормозит сборку maven-war-plugin со своими оверлеями. Собираем каждый модуль в отдельности. Для деплоя используем war, а во время разработки его распакованную версию в target, достаточно было бы, чтобы эта папка обновлялась только инкрементно, war даже перепаковывать не надо. Задумываюсь о доработке плагина :) Есть мысли?