Gradle Dependency Management
Estimated time to read: 3 minutes
Overview¶
Your project can have dependencies on a selection of code, these include;
- Other projects
- External libraries
- Internal libraries
Listing Dependencies¶
Gradle can list out the dependencies of the project by using the following commands:
gradle -q dependencies
- This will list all of the dependencies that are in use across the entire project.
gradle -q dependencies --configuration <implementation>
- This will list only the dependencies that are used within the implementation configuration element.
Transitive Dependencies¶
Some dependencies will depend on other libraries. These are known as transitive dependencies. Gradle will automatically download these when required by another library.
Naming¶
Dependencies are added into gradle via their group, name and version. For example; | group | name | version | | ----- | ----- | ------- | | log4j | log4j | 1.2.17 |
This would be added in to a gradle.build file as follows; implementation 'log4j:log4j:1.2.17'
or implementation '<group>:<name>:<version>'
Dependency Satisfaction¶
Dependencies can be satisfied from:
- File system repository
- Local
- Maven cache
- Remote
- Maven repositories
- Ivy repositories
- Other projects
Adding Repositories¶
File System Repositories¶
repositories {
flatDir {
dirs("lib")
}
}
dependencies {
implementation 'log4j:log4j:1.2.8' // Once a flatDir is added, this can be declared differently.
// implementation files ('lib/log4j-1.2.8.jar') //
implementation group: 'javax.xml.bind', name: 'jaxb-api', version: '2.3.1' // Alternative expression
}
Configuration Scopes¶
Projects may have many configurations, these can differentiated between using the gradle.build file.
There may be dependencies that are only used at:
- Compilation
- Runtime
- Test Compilation
-
Test Runtime
-
implementation - If a dependency is added to the implementation scope, it will be used at compile and runtime for the main code in the application.
- compileOnly - If a dependency is marked as compileOnly, it will only be used during the compilation phase.
- runtimeOnly - If a dependency is marked as runtimeOnly, it will only be used during the runtime phase.
- testImplementation - Used as above, but only within the test scopes. However, the test scopes also inherit from the implementation scopes above.
- testCompileOnly
- testRuntimeOnly
Scope and Constants¶
Kotlin¶
gradle.build.kts¶
var log4j_version: String by project
var jaxb_version: String by project
var junit_version: String by project
dependencies { //Versions are set via the variables above and reference gradle.properties, this is Kotlin specific
implementation("log4j:log4j:$log4j_version") //Dependencies used for implementation scope
implementation("javax.xml.bind:jaxb-api:$jaxb_version")
testImplementation("junit:junit:$junit_version") //Dependencies used for testImplementation scope
}
gradle.properties¶
Groovy¶
buildscript {
ext {
log4J_version = '1.2.17'
}
}
dependencies {
implementation "log4j:log4j:$log4j_version" // Elements including variables need to be double-quoted strings
implementation: 'javax.xml.bind', name: 'jaxb-api', version: '2.3.1'
testImplementation 'junit:junit:3.8.1'
}
Remote Repositories¶
There are a few ways of defining remote repositories.
Well-known Names¶
repositories {
mavenCentral() //Points towards the Maven repository
}
repositories {
jcenter() //Points towards the JFrog BinTrade repository
}
URL¶
Custom Maven¶
Ivy¶
Multiple repositories¶
All of the methods for defining a remote repository above can be used in tandem when specifying multiple repositories in the gradle.build file.
The Gradle Cache¶
- Modules / Libraries are cached
- Reduces latency and bandwidth use
- File based repository
- Metadata and files are stored separately
- Repository caches are independent of the type of repository called
- File names in the path are based on the hash of the file
- Dependencies can be refreshed at will
- Using the
--refresh-dependencies
flag - Can be deleted safely
- Gradle will re-download files as needed