Add dependencies¶
Use built-in dependency notations¶
refreshVersions provides read-to-use organized dependency notations for select popular libraries of the following ecosystems:
- Kotlin Multiplatform
- Kotlin/JVM
- Android
That doesn’t prevent you from using refreshVersions in a Gradle project that is not using Kotlin or is not an Android project.
You can use them in any build.gradle
or build.gradle.kts
file.
Here’s an example of how it looks like in the IDE:
No imports needed.
Autocomplete in IDE for easy discoverability.
You can see all the dependency objects in this directory.
Wait, what version are those dependencies using?¶
All these dependency notations specify their version as the version
placeholder (_
), so refreshVersions can replace them seamlessly with the corresponding
value defined in the versions.properties
file, via Gradle APIs.
After adding a dependency that doesn’t have its version specified in the
versions.properties
file yet, refreshVersions will edit it and put the
most stable recent version in it on the next Gradle sync (or any other
Gradle run).
It will also put any less stable versions as comments, allowing you to quickly upgrade if needed.
Add Gradle plugins¶
This section doesn’t apply to plugins that are configured in a
buildscript
block (since these have their versions configured like
regular dependencies), but only to those that are configured solely with
a plugin id.
To add such a plugin, do as usual, but do not specify the version in the
build.gradle
or build.gradle.kts
file. Instead, set it up like so in
the versions.properties
file:
plugin.com.apollographql.apollo=2.4.1
plugin.com.squareup.sqldelight=1.4.3
Then you can omit the plugin version in all build.gradle(.kts)
of your project:
plugins {
id 'com.squareup.sqldelight'
id 'com.apollographql.apollo'
}
As you see, the convention is pretty simple. The key is the id of the plugin, prefixed by plugin.
: plugin.some.plugin.id
sets the version of the plugin of id some.plugin.id
.
Non-built-in dependency notations¶
Use gradle buildSrcVersions (WIP)¶
Yet another approach to managing dependencies is to use the Gradle buildSrc module, and to automatically generate a file Libs.kt
that contains all the dependencies applied to your build:
/**
* Generated by `$ ./gradlew buildSrcVersions`
*/
object Libs {
const val guava: String = "com.google.guava:guava:_"
const val guice: String = "com.google.inject:guice:_"
}
Because this file used the placeholder version _
, it is compatible with gradle refreshVersions!
This feature is not done yet. If you think we should prioritze it, please vote for this issue with a 👍 and subscribe to it.
Use Package Search from JetBrains¶
JetBrains offers the plugin Package Search.
Package Search provides a nice UX to add a dependency:
Can you use it with refreshVersions?
Sure, just use the version placeholder (_
).
Use the libraries.gradle pattern¶
An older approach to centralize dependencies is to have a libraries.gradle
file:
ext.libraries = [ // Groovy map literal
spring_core: "org.springframework:spring-core:3.1",
junit: "junit:junit:4.10"
]
apply(from = "../libraries.gradle")
dependencies {
compile libraries.spring_core
testCompile libraries.junit
}
Does that work with refreshVersions too? Yes, just use the version placeholder (_
):
ext.libraries = [ // Groovy map literal
- spring_core: "org.springframework:spring-core:3.1",
+ spring_core: "org.springframework:spring-core:_",
- junit: "junit:junit:4.10"
+ junit: "junit:junit:_"
]