Советы по ускорению времени сборки в Linux с помощью ANT, Javacc, JUnit и компиляции классов Java

Одно быстрое исправление, которое может сэкономить некоторое время, - убедиться, что вы используете Ant с серверной JVM (по умолчанию он использует клиентскую виртуальную машину). Установите ANT_OPTS, чтобы включить "-сервер".

• Профилируйте процесс сборки и посмотрите, где находятся узкие места. Это может дать вам некоторые идеи относительно того, как улучшить процесс.
• Попробуйте создавать независимые проекты параллельно на многоядерных машинах / машинах с процессором. В качестве расширения этой идеи вы можете поискать Java-эквивалент distcc (не знаю, существует ли он) для распространения вашей сборки на нескольких машинах.
• Купите машины получше.

Это, вероятно, не поможет в ближайшем будущем, но я решил, что все равно должен выбросить это там.

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

Какая разбивка по затраченному времени:

1. создание классов
2. составление классов
3. запуск тестов

В зависимости от вашего проекта вы можете увидеть значительное увеличение времени сборки, выделив больший размер кучи для javac (memoryMaximumSize) и junit (maxmemory).

Попробуйте вдохновиться прагматичным программистом. Компилируйте только то, что необходимо, имейте два или более набора тестов. Один для быстрых тестов, другой для полных тестов. Подумайте, есть ли реальная необходимость использовать каждый раз каждый шаг сборки. Необходимо попробовать использовать компилятор jikes вместо javac. После того, как проект охватывает несколько сотен занятий, я перехожу на джайки, чтобы улучшить скорость. Но помните о потенциальных проблемах несовместимости. Не забудьте включить все в одну цель для выполнения каждого шага с полной перестройкой и полным тестированием проекта.

Теперь, когда вы объяснили этот процесс более подробно, есть еще два варианта:

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

2. Измените разбиение на подпроекты, чтобы было сложнее разбить один проект, изменив другой. Это должно сделать менее важным выполнение полной сборки перед каждой фиксацией. Только коммиты, которые касаются чувствительных подпроектов, или те, которые охватывают несколько проектов, должны затем быть "проверены" посредством полной сборки.

Очень важно, чтобы сборка весь длилась менее 10 минут? Если вы сделаете подпроекты независимыми друг от друга, вы можете работать над одним подпроектом, уже скомпилировав другие (подумайте, что Maven или Ivy управляют зависимостями).

Другое решение (и если ваши модули достаточно стабильны) - рассматривать ваши подпроекты как отдельные проекты. Затем каждый проект будет следовать своему собственному циклу выпуска и будет доступен в локальном репозитории Maven / Ivy. Это, конечно, хорошо работает, если хотя бы части проекта достаточно стабильны.

несколько советов по сокращению времени сборки:

1. делай меньше работы. например удалить ненужное ведение журнала / эхо в файлы и приставка

2. сделайте вашу сборку "инкрементальной". Компилировать только измененные классы.

3. исключить дублирование усилий. Легче сказать, чем сделать, но если ты убежишь сборку в режиме отладки ("ant -debug") иногда можно увидеть повторяющиеся задачи или цели.

4. избегать дорогостоящих операций. копирование файлов и упаковка jar-файлов в войны необходимы для выпуска. Подписание jar-файлов стоит дорого и должно выполняться, по возможности, только для этапных выпусков, а не для каждой сборки.