Maven. Собираем только измененное

[bugy]

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

По моему мнению лучше не пытаться использовать один vcs репозиторий для всех модулей.
В идеале: один репозиторий – один модуль.
Отчасти согласен. С точки зрения идеальной организации кода это правильно. Но если у вас сотни или тысячи модулей, то порой гораздо удобнее их хранить вместе. В том числе для работы в IDE.

[sndl]

В идеале: один репозиторий – один модуль.

Не совсем согласен, от модулей маленького размера можно получить много преимуществ и не придется создавать сотни репозиториев.

С описанным в статье нам в компании очень помогает Pants, там эта функциональность идет из коробки

./pants changed --include-dependees=transitive --changes-since=f61ad76d5d37d8dae6f1c298e1365af423d9892e

Вот такой командой можно например получить список всех модулей, которые затронули изменения после определенного git коммита.

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

В результате имеем преимущества одного репозитория и сборка не страдает.

[bugy]

@sndl, я правильно понимаю, что Pants это не дополнение к maven, а альтернатива? Т.е. если кто-то уже на maven, глубоко и серьезно, то Pants не поможет?

Так-то есть gradle, который инкрементальный из коробки (помимо других преимуществ перед maven). Но смена билд системы это не всегда легко и просто

[sndl]

Да, это альтернатива, не дополнение.

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

Bazel — в свою очередь сравнимое с Pants

[olegchir]

почему-то от общения с градлями у меня осталось ощущение, что несмотря на инкрементальность, они гораздо более тормозные сами по себе

[bugy]

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

[hibissscus]

Базель вам в помощь https://bazel.build/ он сам определяет измененные зависимости и пересобирает только задетые части. ну или есть очень хорошая вещь под названием http://hotswapagent.org/ агент для IDEA на базе https://dcevm.github.io/ Happy Hot Swapping!

[primetalk]

В нашем проекте мы схожую проблему решаем с помощью gradle. В перспективе можно будет отправить maven на заслуженный отдых (люди к maven привыкли/прикипели и не готовы сразу с ним расстаться).

[bugy]

Могу вам только позавидовать :) Gradle эту проблему действительно решает очень хорошо.
К сожалению, в моем случае перейти на gradle не так просто, но "мы работаем над этим..."

[ashumkin]

но в данном случае приходится работать с тем, что уже есть и менять ничего в проекте для этого нельзя.

а почему нельзя-то?

[bugy]

На текущий момент слишком много заточено на мэйвен. Просто так взять и перейти на что-то более современное будет слишком трудозатратно и не будет иметь много смысла (ведь всё и сейчас работает).
В стратегическом плане, конечно, рано или поздно перейдем, я думаю, но до этого момента нужно ещё как-то дожить.

[bugy]

Если вдруг кто подписан и кому интересно, появилась возможность работы с Git. Пока пробная версия: https://github.com/bugy/incremaven/releases/tag/1.1.3a