Ответ 1
Если вы используете SVN и * nix, из корневого модуля
mvn install -amd -pl $(svn st | colrm 1 8 | sed /.* ' | xargs echo | sed 's- -,:-g' | sed ^ : ')
Предположим, что у меня есть структура модуля, как показано ниже
Modules
->utils
->domain
->client
->services
->deploy (this is at the module level)
Теперь, чтобы понять, что мне нужно сделать сборку всех модулей, i.e utils, domain, client, services,
, потому что я загружаю банки всех вышеперечисленных модулей, чтобы fanchlly lanch the client
И все банки собираются в модуле развертывания.
Мой вопрос в том, что я могу что-то изменить в сервисах, например, есть ли способ, когда запуск сборки из deploy maven
мог распознать, что он должен строить только services
и, следовательно, строить его и разворачивать в папке развертывания?
Если вы используете SVN и * nix, из корневого модуля
mvn install -amd -pl $(svn st | colrm 1 8 | sed /.* ' | xargs echo | sed 's- -,:-g' | sed ^ : ')
Если вы вызываете только "mvn install" без "clean", плагин компилятора будет компилировать только измененные классы.
В многомодульной сборке вы можете использовать:
mvn -pl ChangedModule compile
из корневого модуля будет компилировать только данный ChangedModule. Плагин компилятора только скомпилирует файлы, которые были изменены. Но может случиться так, что модуль, который вы изменили, приведет к перекомпиляции другого модуля, который зависит от ChangedModule. Этого можно достичь, используя следующее:
mvn -amd -pl ChangedModule compile
где -amd означает также делает иждивенцев. Это будет работать без установки всех модулей в локальный репозиторий с помощью mvn install.
Для GIT
mvn install -amd -pl $(git status | grep -E "modified:|deleted:|added:" | awk '{print $2}' | cut -f1 -d"/")
ИЛИ ЖЕ
В вашем файле .bashrc (.bashrc можно найти в домашнем каталоге ~/.bashrc или создайте его, если он не существует) добавьте следующую функцию.
mvn_changed_modules(){
[ -z "$1" ] && echo "Expected command : mvn_changed_modules (install/build/clean or any maven command)" && exit 0
modules=$(git status | grep -E "modified:|deleted:|added:" | awk '{print $2}' | cut -f1 -d"/")
if [ -z "$modules" ];
then
echo "No changes (modified / deleted / added) found"
else
echo "Changed modules are : 'echo $modules'"
mvn install -amd -pl $modules
fi
}
Затем, после перезапуска bash (командной строки), вы можете просто использовать следующую команду из самого каталога ROOT.
smilyface @machine> MainDir] $ mvn_changed_module установить
Как это устроено?
Согласно Вопросу mvn install -amd -pl services
- это команда, когда "некоторые изменения сделаны в сервисном модуле". Итак, сначала получите имя модуля из измененного файла (ов) и поместите его в качестве ввода для команды mvn-install
Скажем, например, ниже приведен список измененных файлов (вывод состояния git status
) -
услуги/pom.xml
услуги/ReadMe.txt
web/src/java/com/some/Name.java
Тогда services
и web
- это имена модулей, которые нужно собрать/собрать/установить
После попытки использования вышеупомянутых советов я столкнулся с следующими проблемами:
Что действительно для меня работало, это сравнение дат модификации источника с модификацией .jar в локальном репозитории. И если вы проверяете только измененные файлы VCS (см. Sebasjm answer), то сравнение даты не займет заметного времени (для меня это было менее 1 с для 100 измененных файлов). Главным преимуществом такого подхода является очень точная перестройка только реально измененных проектов. Основная проблема заключается в том, что сравнение даты сравнения немного больше, чем однострочный script.
Для тех, кто хочет попробовать, но слишком ленив, чтобы написать такой script сам, используя мою версию: https://github.com/bugy/rebuilder (linux/windows). Он может делать некоторые дополнительные полезные вещи, но основная идея и центральный алгоритм описаны выше.
У меня было такое же разочарование, и я также написал проект в то время - увы, он недоступен, но я нашел людей, которые реализовали нечто подобное:
например - https://github.com/erickzanardo/maven-watcher
Он использует nodejs
и предполагает проект maven
, но должен работать как с окнами, так и с unix.
Идея моей реализации - следить за изменениями, а затем компилировать то, что изменилось. - вроде как nodemon
.
Итак, например
И они не связаны друг с другом.. поэтому, если компиляция java не удалась, не должно быть причин для обновления файла jar.. и это довольно стабильно.
Я использовал его в проекте с 23K .java
файлами, и он работал плавно.
Для начала потребовалось пару секунд, чтобы начать - но тогда он будет работать только при обнаружении изменений, поэтому общий опыт был приятным.
Следующий шаг, который я намеревался добавить, похож на вашу поддержку SVN - перечислить измененные файлы и использовать их в качестве инициализации.
Важно отметить, что если компиляция завершилась неудачно, она повторит следующую модификацию. поэтому, если вы изменяете несколько банок, а компиляция не работает, пока вы пишете код, она будет пытаться скомпилировать все на каждом изменении кода, пока оно не будет скомпилировано.
Если вы хотите попробовать мой старый проект, исправьте его и опубликуйте.