На счёт 3rd-party зависимостей: если что-либо есть уже в продакшн коде, то значит работает более менее стабильно и оставляем эту завистмость. Но бывает множество исключений -> в таких случаях просто оставляем в sample ближайшем по контексту модуле. И в случае необходимости вставляется отдельно в конкретный проект (копипастом).

А вот проблема с зависимостями от своих же модулей ещё не совсем у нас решена. В планах попытаться разбить на более мелкие составляющие, так что вопрос ещё открыт.

Можешь подробнее описать, с чем конкретно проблемы?

а как вы поддерживаете актуальность информации, если не секрет?

Путем ее обновления регулярного

Наверное 😃

Ты про документацию?

Да и про реализации

я вот присоединяюсь к вопросу Владимира.

В вашей компании все разработчики уделяют внимание этому проекту, или определенная группа?

Документация держится в актуальном состоянии за счёт пулл реквестов. Реализация по мере необходимости, например если находится баг то он сразу правится силами команды, нашедшей его

Да, все разработчики

Я по сути вырезаю куски продакшн кода в модули, и там то тимбер мелькнет, то nullable-аннотация з саппорта и т.д. И выходит, что их надо подключать к каждому модулю. Для этого надо выработать стратегии по версионированию, чтобы не было конфликтов, а так-же вопрос выбора api/implementation мне не до конца понятен.

Спасибо за ответ.

Версии у нас указываются в одном файле для всего android-standard - в config.gradle. Насчёт сторонних зависимостей - чем их меньше тем лучше, мы например сделали свой аналог тимбера для этого.

В целом я для себя рабочую схему нашел, сейчас испытываю. У меня будет три гитовых проекта, core (абстрактные объвязки над сетью, парсингом, работой со звуком и т.д.), common (модули бизнес-логики) и ui-kit (кастомные вьюхи, стили, анимации и т. д.). В рамках своего репозитория модули будут иметь каждый свой артефакт, и друг от друга зависеть могут, но только через мейвен, а не compile project(). Вне репозитория только common от core, при чем только на релизную версию. Версии, как у вас, буду держать в отдельном config.gradle файле, и между репозиториями уже придется мануально согласовывать. Но это меньшее из зол, да и есть подозрение, что это не то чтобы часто придется делать, и я занимаюсь преждевременной оптимизацией.

Насчёт api и implementation - это тебе в официальные доки,  там вроде хорошо описано было

Мы пока не разделили наш проект не несколько репозиториев как раз из-за проблем с версиями по большей части. Для того чтобы это стабильно работало нужно накрутить сверху серьезный ci. Мы будем это делать в ближайшем будующем

Если проект один, то разделять на несколько репозиториев нет смысла. У нас была подобная схема, в итоге вернулись к одному репозиторию с несколькими модулями. Больше проблем было из-за PR (постоянно надо проверить несколько репозиториев).

Разницу я знаю, я скорее о стратегии выбора. Скрывать тот же тимбер на всех уровнях, или пробрасывать с нижнего и на верх по графу зависимости модулей. Второй вариант вроде как проще, но может выйти что при подключении высокоуровенго  модуля на три класса в довесок прилетит условный rx. Я думал не завести ли какой-то common-sdk модуль, который бы содержал api зависимстей, которые 100% и так будут в конечном apk, а для остальных использовать implementation, но как-то красивая картинка в голове не сложилась.

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