Pull to refresh

Comments 13

UFO just landed and posted this here

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


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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

Only those users with full accounts are able to leave comments. Log in, please.

Articles