Comments 23
Может быть чуть больше текста стоит убрать под кат? ;)
Очень полезно. Спасибо.
А запуски юнит тестов оно не делает паралельными?
А запуски юнит тестов оно не делает паралельными?
Если ничего не помогло, или если вы недовольны Maven-ом (как многие, очень многие), то вот вам радикальное решение — перепишите сборку на Gradle.
В плане скорости сборки у них есть совершенно убийственная фича — инктрементальная сборка. Идея состоит в том, что каждая задача определяет свои вводы и выводы (например для задачи javac это будут — исходники и бинарники соответственно). Перед запуском задачи Gradle проверяет вводы и выводы и если ни те, ни другие не изменились, задача не будет бежать вообще.
Ну и кроме того, у них, естественно, есть все, что есть в Maven-е, будь то многопоточное исполнение или исполняемый на фоне демон-процесс для ускорения инициализации.
В плане скорости сборки у них есть совершенно убийственная фича — инктрементальная сборка. Идея состоит в том, что каждая задача определяет свои вводы и выводы (например для задачи javac это будут — исходники и бинарники соответственно). Перед запуском задачи Gradle проверяет вводы и выводы и если ни те, ни другие не изменились, задача не будет бежать вообще.
Ну и кроме того, у них, естественно, есть все, что есть в Maven-е, будь то многопоточное исполнение или исполняемый на фоне демон-процесс для ускорения инициализации.
Я пробовал собирать один из рабочих проектов 3-й версией мавена, и не получил практически никакого прироста. Сборка в параллель будет хорошо работать только в том случае, если нет «тяжелых» модулей (как правильно указал автор). Если они есть, особого прироста тоже не будет (в моем случае, вместо 9 минут получилось 8). Еще один момент — не все последние версии плагинов в данный момент thread safe.
Раз уж речь в коментах зашла о TeamCity, то я обратил бы внимание на одну из ключевых возможностей, которые появились в 7-й версии — инкрементальную сборку. В этом случае TC с помощью собственных механизмов определяет модули, которые затронули закоммиченные изменения, и билдит только то, что нужно. Подробнее можно почитать здесь.
Раз уж речь в коментах зашла о TeamCity, то я обратил бы внимание на одну из ключевых возможностей, которые появились в 7-й версии — инкрементальную сборку. В этом случае TC с помощью собственных механизмов определяет модули, которые затронули закоммиченные изменения, и билдит только то, что нужно. Подробнее можно почитать здесь.
Статья ни о чем, можно было бы просто привести ссылку на выхлоп mvn --help с выделением следующего куска:
-T,--threads Thread count, for instance 2.0C where C is core multiplied
все.
И кстати, мавен тоже умеет не компилировать неизменившиеся сырцы.
-T,--threads Thread count, for instance 2.0C where C is core multiplied
все.
И кстати, мавен тоже умеет не компилировать неизменившиеся сырцы.
>>И кстати, мавен тоже умеет не компилировать неизменившиеся сырцы.
Как?
Как?
да, был неправ, пример с сорцами дурацкий. javac сам умеет не компилировать не изменившиеся сорцы. А как на счет, например, не перепаковывать jar?
JAR не надо перепаковывать, только если вы вообще ничего не поменяли. Я не уверен в том как эту ситуацию обработает Maven, но зачем вообще такое пытаться собрать?
Ну, Maven-же не знает, поменяли вы или нет. Вы поменяли что-то в каком-то модуле. Запускаете Maven в рутового проекта. Все, кроме javac, который сам знает, что ничего компилировать не нужно, будет бежать заново — генерация сорцов из дескрипторов, которые не поменялись (например), тесты на классы, которые не поменялись, запаковка в jar-ы файлов, которые не поменялись, и так далее.
javac определяет неизменность исходника сравнивая время изменения исходника со временем создания .class Ни что на самом деле не мешает assembly плагину проверить время создания всех файлов участвующих в запаковке и ничего не делать если уже готовый архив новее.
Реализовано это или нет, к сожалению, сейчас не могу проверить. На сколько это оправдано в смысле экономии, тоже неоднозначно. Но факт в том что реализуемо и достаточно легко.
Реализовано это или нет, к сожалению, сейчас не могу проверить. На сколько это оправдано в смысле экономии, тоже неоднозначно. Но факт в том что реализуемо и достаточно легко.
Ну, тот факт, что ничто с технологической точки зрения не мешает Мавену сосать, не значит что он не сосет, увы и ах.
Грейдл лишь подтверждает тот факт, что система сборки может быть намого лучше и умнее, чем Мавен.
Грейдл лишь подтверждает тот факт, что система сборки может быть намого лучше и умнее, чем Мавен.
То что вам больше нравится другой инструмент вовсе не означает того, что вам дано право оскорбительно отзываться о других инструментах, которые вполне успешно справляются со многими поставленными задачами.
2/3 мои проектов собираются Maven и я знаю в нем много достоинств и недостатков, однако при этом я не позволяю себе столь мерзких суждений в отношении других сборщиков, да и вообще инструментов, которые я использую.
Если вам что то не нравится, не пользуйтесь этим!
2/3 мои проектов собираются Maven и я знаю в нем много достоинств и недостатков, однако при этом я не позволяю себе столь мерзких суждений в отношении других сборщиков, да и вообще инструментов, которые я использую.
Если вам что то не нравится, не пользуйтесь этим!
>>И кстати, мавен тоже умеет не компилировать неизменившиеся сырцы.
Как?
Как?
Maven Shell не поможет на больших проектах. Проблема в баге maven compiler plugin, который приводит к утечке памяти в ClassLoader'е. Как результат, спустя несколько запусков mvnsh бодро валится с OutOfMemoryError.
Этот неприятный баг сильно нивелирует достоинства mvnsh. Нет особого смысла кешировать библиотеки, если спустя пару-другую сборок придётся перезапускать шелл. Особого выигрыша в скорости не возникает, не говоря уже о том, что сам процесс сборки становится менее предсказуемым и более нервным.
Наращивание места под PermGen лишь отсрочит проблему, но не решит её. Падения станут происходить чуть реже, но за счёт занятой памяти. Это не похоже на выгодную сделку…
Этот неприятный баг сильно нивелирует достоинства mvnsh. Нет особого смысла кешировать библиотеки, если спустя пару-другую сборок придётся перезапускать шелл. Особого выигрыша в скорости не возникает, не говоря уже о том, что сам процесс сборки становится менее предсказуемым и более нервным.
Наращивание места под PermGen лишь отсрочит проблему, но не решит её. Падения станут происходить чуть реже, но за счёт занятой памяти. Это не похоже на выгодную сделку…
В моем случае разбиение на модули хорошее, но сильно тормозит сборку maven-war-plugin со своими оверлеями. Собираем каждый модуль в отдельности. Для деплоя используем war, а во время разработки его распакованную версию в target, достаточно было бы, чтобы эта папка обновлялась только инкрементно, war даже перепаковывать не надо. Задумываюсь о доработке плагина :) Есть мысли?
Only those users with full accounts are able to leave comments. Log in, please.
Ускоряем процесс сборки с maven