Привет! Меня зовут Ксения Кайшева, я пишу приложения под Android в компании 65apps. Сегодня расскажу о новой возможности, которая позволяет централизованно описывать зависимости на проектах с системой сборки Gradle.
На текущий момент существует множество вариантов описания зависимостей в проектах, использующих Gradle. Рекомендуемого стандарта нет, поэтому используются самые разные подходы: кто-то просто перечисляет зависимости в блоке dependencies, кто-то выносит зависимости в отдельный файл, блок ext и т.д. И для новых разработчиков не всегда очевидно, что, где и как используется в большом и многомодульном проекте.
В 7й версии Gradle представлена новая функция, позволяющая описывать все зависимости централизованно. Эта функция находится на стадии превью, и чтобы воспользоваться ей в файле settings.gradle(.kts) необходимо добавить строку:
enableFeaturePreview("VERSION_CATALOGS")
Так выглядит использование (описанных в централизованном каталоге) зависимостей в любом build.gradle скрипте:
dependencies {
implementation libs.lifecycle.runtime
implementation libs.lifecycle.viewmodel.ktx
implementation libs.lifecycle.extentions
implementation libs.lifecycle.livedata.ktx
}
Здесь:
libs это сам каталог
lifecycle.runtime это зависимость в этом
каталоге.
Каталог описывается в
settings.gradle(.kts) файле:
dependencyResolutionManagement {
versionCatalogs {
libs {
alias('lifecycle-runtime')
.to(androidx.lifecycle:lifecycle-runtime:2.2.0')
alias('lifecycle-viewmodel-ktx').to(androidx.lifecycle',
'lifecycle-viewmodel-ktx').version {
strictly '[2.2.0, 2.3.0['
prefer '2.3.1'
}
}
}
}
Псевдоним (alias) должен состоять из имен, которые могут быть разделены тире, нижним подчеркиванием или точкой.
Разделение через тире является рекомендованным.
Сами имена должны состоять из буквенных символов, предпочтительно в нижнем регистре. Числа можно использовать в конце имени.
Например,
lifecycle-runtime
lifecycle_runtime
lifecycle.runtime
junit5-test-core
spek-runner-junit5
Недопустимо иметь псевдоним для зависимости, которая также принадлежит вложенной группе. Например, lifecycle-viewmodel и lifecycle-viewmodel-ktx.
Gradle рекомендует в таком случае использовать регистр для
различения.
Например, lifecycleViewmodel и
lifecycleViewmodelKtx.
Версии можно объявлять отдельно и затем ссылаться на них в описаниях самих зависимостей:
dependencyResolutionManagement {
versionCatalogs {
libs {
version('lifecycle', '2.3.1')
alias('lifecycle-viewmodel-ktx').to('androidx.lifecycle',
'lifecycle-viewmodel-ktx').versionRef('lifecycle')
}
}
}
Объявленные таким образом версии также доступны из любогоbuild.gradle файла:
version = libs.versions.lifecycle.get()
Часто бывает, что некоторые зависимости используются вместе. В каталоге такие зависимости можно объединять в пакеты и подключать их сразу через псевдоним пакета. То есть пакет это список нескольких зависимостей:
dependencyResolutionManagement {
versionCatalogs {
libs {
version('lifecycle', '2.3.1')
alias('lifecycle-runtime').to('androidx.lifecycle,
'lifecycle-runtime').versionRef('lifecycle')
alias('lifecycle-viewmodel-ktx').to('androidx.lifecycle,
'lifecycle-viewmodel-ktx').versionRef('lifecycle')
bundle('lifecycle',
['lifecycle-runtime', 'lifecycle-viewmodel-ktx'])
}
}
}
Подключение пакета зависимостей будет выглядеть так:
dependencies {
implementation libs.bundles.lifecycle
}
Добавление одного пакета эквивалентно добавлению всех зависимостей из пакета по отдельности.
Помимо описания каталога в settings.gradle(.kts) файле, есть более простая возможность собрать все зависимости вместе использовать toml-файл каталоге gradle: libs.versions.toml.
То есть, плюс еще один стандарт к представленному стандарту описания зависимостей.
По умолчанию libs.versions.toml файл будет входом в libs каталог. Можно также изменить имя каталога по умолчанию, например:
dependencyResolutionManagement {
defaultLibrariesExtensionName.set('deps')
}
Toml-файл состоит из 3 основных разделов:
[versions] - раздел для объявления версий
[libraries] - раздел для объявления
зависимостей
[bundles] - раздел для объявления пакетов
зависимостей
Например,
[versions]
lifecycle = "2.3.1"
[libraries]
lifecycle-runtime = { module =
"androidx.lifecycle:lifecycle-runtime", version.ref = "lifecycle"
}
lifecycle-viewmodel-ktx = { module =
"androidx.lifecycle:lifecycle-viewmodel-ktx", version.ref =
"lifecycle" }
[bundles]
dagger = ["lifecycle-runtime",
"lifecycle-viewmodel-ktx"]
Версию можно объявить просто как строку с номером, и в этом случае она считается обязательной версией, или в расширенном варианте, комбинируя информацию о версиях разного уровня:
[versions]
any-lib1 = 1.0
any-lib2 = { strictly = "[1.0, 2.0[", prefer = "1.2" }
Более подробно о расширенном варианте версии по ссылке
Семантика объявления номера версии по ссылке
Саму зависимость можно прописать, указав полное имя или отделив версию от группы и имени:
[libraries]
any-lib = "com.company:anylib:1.4"
any-other-lib = { module = "com.company:other", version="1.4" }
any-other-lib2 = { group = "com.company", name="alternate",
version="1.4" }
anylib-full-format = { group = "com.company", name="alternate",
version={ require = "1.4" } }
Если необходимо сослаться на версию, объявленную в [versions] разделе, то следует использовать свойство version.ref:
[versions]
some = "1.4"
[libraries]
any-lib = { group = "com.company", name="anylib",
version.ref="some" }
Можно использовать несколько toml-файлов.Для этого нужно указать, как импортировать соответствующий файл:
dependencyResolutionManagement {
versionCatalogs {
testLibs {
from(files('gradle/test-libs.versions.toml'))
}
}
}
Также есть возможность создать каталог зависимостей и использовать его между разными проектами в рамках одной компании, например.
Новая функциональность Gradle в целом неплоха, с ней действительно удобнее централизованно описывать все зависимости в проекте. Но пока есть некоторые неудобства в работе с ней. Например, не подсвечивается номер версии зависимости, которую можно обновить. Хотя, уже есть плагины решающие эту проблему.
При использовании Groovy не работает автоподстановка при указании зависимости в build.gradle файле и, соответственно, нет возможности провалиться в описание зависимости при нажатии на нее. Исправлять это не планируют. Решение для автоподстановки использовать Kotlin DSL.
