Я использую локальный артефакт для проксирования запроса, но этапы сборки и тестирования все еще немного медленны. Это не фактическая компиляция и медленные тесты, это «разогрев» фреймворка maven2. Есть идеи?
Я нашел эта статья полезным. Мне хорошо подходит ограничение доступа в Интернет.





Я не знаю, какую версию Maven вы используете, я предполагаю, что это 2, но я дам то, что использую для Maven 1.x, чтобы ускориться и немного ускорить создание вещей.
Они превратят тесты junit в новый процесс (также помогает, когда вы используете переменные среды в тестах и т. Д., И дает тестам немного больше памяти.
-Dmaven.junit.fork=true
-Dmaven.junit.jvmargs=-Xmx512m
Это разветвляет компиляцию, которая может ускорить работу для вас.
-Dmaven.compile.fork=true
Надеюсь, это может немного помочь, попробуйте.
Также обратитесь к получите больше скорости с вашей сборкой maven2.
Я использую maven2, но это хорошая ссылка, и я обязательно попробую эту исправленную версию для своих загрузок. Однако проблема заключалась в увеличении времени запуска сборки и тестирования ...
Включение вилки сделало мой проект немного быстрее
Я обнаружил, что анализ проектов реакторов происходит значительно медленнее, чем проекты с одним помпоном. Если ваша сборка является реактором (многомодульной) и ваши разработчики не работают над всеми модулями одновременно, вы можете удалить родительский POM и построить их отдельно, разрешив зависимости с помощью локального репо. Недостатком является то, что вам необходимо установить или развернуть модуль, чтобы его иждивенцы могли видеть изменения.
Кроме того, вы можете взглянуть на новый Maven 2.1 M1, который содержит несколько значительных улучшений скорости.
Если ничего из этого не помогает, опубликуйте более подробную информацию о конфигурации вашего проекта (структура модулей и плагины), параметрах командной строки и конфигурации оборудования (память и диск). Запуск Maven с -X также может показать, на что он тратит время.
это действительно проект реактора, который я использую. три небольших модуля и веб-проект. Я попробовал эту сборку 2.1, и она показалась мне немного быстрее.
Есть несколько возможностей для оптимизации некоторых задач сборки. Например, «чистую» задачу можно оптимизировать с минут до миллисекунд с помощью простого трюка - переименовать «целевую» папку вместо удаления.
Чтобы узнать, как это сделать, обратитесь к Ускорить сборку Maven.
изящные уловки, я тоже часто трачу ненужное время на чистую задачу.
Некоторое время я занимался этой проблемой и нашел время, чтобы написать об этом сообщение в блоге ... надеюсь, это поможет другим! urbancat.org/2012/05/how-to-speed-maven-up.html
@nadav ссылка больше не работает. Не могли бы вы это исправить?
Я бы использовал локально установленный Nexus.
Нексус тоже хорош. Я использовал и nexus, и artifactory, и они оба довольно быстрые. Nexus немного проще настроить IMO
Что делает Nexus, чтобы помочь этому процессу?
Вы можете использовать -DskipTests=true, чтобы пропустить модульные тесты. что ускорит сборку
Так что вообще не делать никаких тестов ..?
Робот CI будет делать все это при сборке, поэтому они должны быть там.
-o указание автономного режима помогает, поскольку он не смотрит на удаленные обновления для снимков
Отрегулируйте конфигурацию памяти до оптимальной, например: добавьте эту строку в mvn.bat установить MAVEN_OPTS = -Xmx512m -XX: MaxPermSize = 256m
Фаза очистки mvn обычно удаляет целевую папку. Вместо этого, если мы переименовываем целевую папку, этап очистки будет намного быстрее. <Быстрая чистка>
-Dmaven.test.skip = true пропустит выполнение теста.
Добавьте -Denforcer.skip = true в аргумент командной строки mvn (это принудительные версии maven, jdk и т. д., Мы можем пропустить его после начального запуска)
Отключите некритические операции на этапе сборки: анализ, создание javadoc, упаковка исходного кода. Это сэкономит кучу времени.
Создание нового процесса также помогает улучшить время -Dmaven.junit.fork = true (включить тесты junit в новый процесс) -Dmaven.compile.fork = true (вилка компиляции)
Надеюсь, это поможет.
Если вы используете Maven3 ($ mvn -version), вы также можете следовать этому гид. В моем случае результаты следующие:
Нормальное исполнение:
$ mvn clean install
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 03:05 min
[INFO] Finished at: 2015-07-15T11:47:02+02:00
[INFO] Final Memory: 88M/384M
С параллельной обработкой (4 потока):
$ mvn -T 4 clean install
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 02:22 min (Wall Clock)
[INFO] Finished at: 2015-07-15T11:50:57+02:00
[INFO] Final Memory: 80M/533M
Параллельная обработка (2 потока на ядро)
$ mvn -T 2C clean install
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 02:12 min (Wall Clock)
[INFO] Finished at: 2015-07-15T12:00:29+02:00
[INFO] Final Memory: 87M/519M
[INFO] ------------------------------------------------------------------------
Как видим, разница почти в минуту, около 20-30% от прироста скорости.
Первоначально вы должны получить более точный анализ времени сборки, используя что-то вроде это, и определить кандидатов, которые занимают больше всего времени.
Увеличивают ли тесты базу данных H2 за тест? Загрузка внешних файлов jar занимает много времени? Это подскажет, на чем сосредоточить ваше расследование. Простое применение флагов go-fast обычно не работает, поскольку они уже были бы включены по умолчанию, и вы не хотите жертвовать своими тестами с помощью флагов пропуска.
Если вы найдете хороший ответ вне диапазона (например, на других сайтах), мы были бы очень признательны, если бы вы разместили его здесь в качестве ответа.