Проекты в Gradle 7: как не зависеть от зависимостей

[mike114]

Немного не по теме, но я часто вижу, что во многих проектах разработчики практикуют вынесение зависимостей в отдельный файл, даже если у них приложение состоит из одного модуля (про случаи когда простейшее приложение разбивается на несколько модулей только потому, что это clean architecture и все такое я промолчу). Вот реально, какой от этого прок? Неужели это лучше чем в одном месте иметь наглядный и короткий список зависимостей? Да, некоторые группы могут иметь один и тот же номер версии, но можно этот номер просто указать как переменную перед блоком зависимостей и использовать ее.

[DmitriyMX]

Для мелких проектов это конечно же «оверхэд».
А для многомодульных проектов это полезно в первую очередь тем, что не разрастается зоопарк из версий зависимостей. Т.е. случайно не получится так, что Модуль-1 имеет Spring 5.1, а Модуль-2 — Spring 5.2. Так же это удобно при обновлении версий теж же зависимостей: в одном месте поменял и поменялось везде.
Но в вакууме такую дискуссию разводить не хочется, т.к. от проекта к проекту будут свои тонкости и нюансы. В плоть до «так исторически сложилось».

[yavfast]

А можно ещё зависимости или их группы с конфигами и манифестами выносить в отдельные модуля, который будет состоять только из манифеста и build.gradle. Линковка происходит через этот модуль. Это оказалось самым удобным методом, да и сборка всего проекта происходит намного быстрее.
Например, все либы фейсбука засовываем в отдельный модуль с названием facebook, гугловые — в gsm, саппорт либы — в androidx, и т.д. Если что-то надо заиспользовать, то подключается соответствующий модуль.
Также удобно управлять версиями и конфигами, так как все в одном месте.

[Sad_Bro]

Это что-то вроде bom?

[AlexeyOs]

Не совсем понимаю, вот есть две библиотеки

Мы вынесли зависимости в отдельный файл, ведем учёт всевозможных версий

• раздел для объявления версий
• раздел для объявления зависимостей
• раздел для объявления пакетов зависимостей

Но в какой-то момент у нас получилось две библиотеки, который ссылаются на третью библиотеку разных версий? Чем здесь помогают все эти правила? Локализовать проблему? И если решить то как?

[adev_one]

В runtime всё равно будет использоваться какая-то одна версия транзитивной зависимости. В случае Gradle — самая новая из указанных (version 2)

[ra314ra]

Интересно, зачем Gradle всё усложняет?
Эта «фича» свежего релиза — это же дополнительный уровень абстракции, не говоря уже о том, что сам Gradle это тоже куча уровней абстракции над сборкой, через которые очень трудно было «продраться» к понимаю того, что же там в итоге происходит.
Я бы предпочел зайти в один файл build.gradle, и там явно увидеть все зависимости, чем держать в голове еще один файл, в котором что-то переопределяется/расширяется.

[DmitriyMX]

Ваше высказывание справедливо для малых и средних проектов. Для крупных многомодульных проектов и создана описанная фича. Просто раньше это решалось «велосипедами», а теперь есть «из коробки» решение

[some1else]

Недавно в команде смотрели на эту фичу. Однако, артефакт какой нибудь библиотеки конкретной версии для Scala традиционно содержит версию языка в виде суффикса в имени этого артефакта. Поэтому, красиво сделать версию Scala в виде переменной в toml не получается, напрашиваются расширения в Kotlin. Ждём, когда что-нибудь на этот счёт придумают

[DmitriyMX]

Хочу добавить очень важное замечание к данной фиче: она не умеет работать с classifier суфиксами.

Так, например, в Gradle 7.2 следующий код будет инвалидным:

alias('lwjgl-rt-api').to('org.lwjgl:lwjgl:3.2.3:natives-windows')