Example 43.18. Dependency configurations for project
build.gradle
dependencies {
compile project(path: ':api', configuration: 'spi')
}
43.4.10. Dependency reports
You can generate dependency reports from the command line (see Section 11.5.3, “Listing proje dependencies”). With the help of the Project report plugin (see Chapter 39, The Project Report Plugin) such a report can be created by your build.
43.5. Working with dependencies
For the examples below we have the following dependencies setup:
Example 43.19. Configuration.copy
build.gradle
configurations { sealife alllife
}
dependencies {
sealife "sea.mammals:orca:1.0", "sea.fish:shark:1.0", "sea.fish:tuna:1.0" alllife configurations.sealife
alllife "air.birds:albatros:1.0"
}
The dependencies have the following transitive dependencies: shark-1.0 -> seal-2.0, tuna-1.0
orca-1.0 -> seal-1.0 tuna-1.0 -> herring-1.0
You can use the configuration to access the declared dependencies or a subset of those:
Page 227 of 343
Example 43.20. Accessing declared dependencies build.gradle
task dependencies << {
configurations.alllife.dependencies.each { dep -> println dep.name } println()
configurations.alllife.allDependencies.each { dep -> println dep.name } println()
configurations.alllife.allDependencies.findAll { dep -> dep.name != 'orca'
}
Output of gradle -q dependencies
> gradle -q dependencies albatros
albatros orca shark tuna
albatros shark tuna
dependencies returns only the dependencies belonging explicitly to the configuration. allDependencies includes the dependencies from extended configurations.
To get the library files of the configuration dependencies you can do:
Example 43.21. Configuration.files
build.gradle
task allFiles << { configurations.sealife.files.each { file ->
println file.name
}
}
Output of gradle -q allFiles
> gradle -q allFiles orca-1.0.jar shark-1.0.jar tuna-1.0.jar seal-2.0.jar herring-1.0.jar
Sometimes you want the library files of a subset of the configuration dependencies (e.g. of a single dependency).
Page 228 of 343
Example 43.22. Configuration.files with spec
build.gradle
task files << {
configurations.sealife.files { dep -> dep.name == 'orca' }.each { file -> println file.name
}
}
Output of gradle -q files
> gradle -q files orca-1.0.jar seal-2.0.jar
The Configuration.files method always retrieves all artifacts of the whole configuration. It then filters the retrieved files by specified dependencies. As you can see in the example, transitive dependencies are included.
You can also copy a configuration. You can optionally specify that only a subset of dependencies from the original configuration should be copied. The copying methods come in two flavors. The copy method copies only the dependencies belonging explicitly to the configuration. The copyRecursive method copies all the dependencies, including the dependencies from extended
configurations.
Example 43.23. Configuration.copy
build.gradle
task copy << {
configurations.alllife.copyRecursive { dep -> dep.name != 'orca' }.allDepe println dep.name
}
println() configurations.alllife.copy().allDependencies.each { dep ->
println dep.name
}
}
Output of gradle -q copy
> gradle -q copy albatros
shark tuna
albatros
It is important to note that the returned files of the copied configuration are often but not always the same than the returned files of the dependency subset of the original configuration. In case of version conflicts between dependencies of the subset and dependencies not belonging to the
Page 229 of 343
subset the resolve result might be different.
Example 43.24. Configuration.copy vs. Configuration.files
build.gradle
task copyVsFiles << {
configurations.sealife.copyRecursive { dep -> dep.name == 'orca' }.each { println file.name
}
println()
configurations.sealife.files { dep -> dep.name == 'orca' }.each { file -> println file.name
}
}
Output of gradle -q copyVsFiles
> gradle -q copyVsFiles orca-1.0.jar seal-1.0.jar
orca-1.0.jar seal-2.0.jar
In the example above, orca has a dependency on seal-1.0 whereas shark has a dependency on seal-2.0. The original configuration has therefore a version conflict which is resolved to the newer seal-2.0 version. The files method therefore returns seal-2.0 as a transitive dependency of orca. The copied configuration only has orca as a dependency and therefore there is no version conflict and seal-1.0 is returned as a transitive dependency.
Once a configuration is resolved it is immutable. Changing its state or the state of one of its dependencies will cause an exception. You can always copy a resolved configuration. The copied configuration is in the unresolved state and can be freshly resolved.
To learn more about the API of the configuration class see the API documentation:
Configuration.
43.6. Repositories
Gradle repository management, based on Apache Ivy, gives you a lot of freedom regarding repository layout and retrieval policies. Additionally Gradle provides various convenience method to add pre-configured repositories.
You may configure any number of repositories, each of which is treated independently by Gradle. If Gradle finds a module descriptor in a particular repository, it will attempt to download all of the artifacts for that module from the same repository. Although module meta-data and module artifacts must be located in the same repository, it is possible to compose a single repository of multiple URLs, giving multiple locations to search for meta-data files and jar files.
There are several different types of repositories you can declare:
Page 230 of 343
Table 43.2. Repository types
Type |
Description |
Maven central repository |
A pre-configured repository that looks for dependencies in Maven |
|
Central. |
Maven local repository |
A pre-configured repository that looks for dependencies in the local |
|
Maven repository. |
Maven repository |
A Maven repository. Can be located on the local filesystem or at |
|
some remote location. |
Ivy repository |
An Ivy repository. Can be located on the local filesystem or at |
|
some remote location. |
Flat directory repository |
A simple repository on the local filesystem. Does not support any |
|
meta-data formats. |
43.6.1. Maven central repository
To add the central Maven 2 repository (http://repo1.maven.org/maven2) simply add this to your build script:
Example 43.25. Adding central Maven repository
build.gradle
repositories { mavenCentral()
}
Now Gradle will look for your dependencies in this repository.
43.6.2. Local Maven repository
To use the local Maven cache as a repository you can do:
Example 43.26. Adding the local Maven cache as a repository
build.gradle
repositories { mavenLocal()
}
43.6.3. Maven repositories
For adding a custom Maven repository you can do:
Page 231 of 343
Example 43.27. Adding custom Maven repository
build.gradle
repositories { maven {
url "http://repo.mycompany.com/maven2"
}
}
Sometimes a repository will have the POMs published to one location, and the JARs and other artifacts published at another location. To define such a repository, you can do:
Example 43.28. Adding additional Maven repositories for JAR files
build.gradle
repositories { maven {
//Look for POMs and artifacts, such as JARs, here url "http://repo2.mycompany.com/maven2"
//Look for artifacts here if not found at the above location artifactUrls "http://repo.mycompany.com/jars"
artifactUrls "http://repo.mycompany.com/jars2"
}
}
Gradle will look at the first URL for the POM and the JAR. If the JAR can't be found there, th artifact URLs are used to look for JARs.
43.6.3.1. Accessing password protected Maven repositories
To access a Maven repository which uses basic authentication, you specify the username and password to use when you define the repository:
Example 43.29. Accessing password protected Maven repository
build.gradle
repositories { maven {
credentials { username 'user'
password 'password'
}
url "http://repo.mycompany.com/maven2"
}
}
It is advisable to keep your username and password in gradle.properties rather than directly
in the build file.
Page 232 of 343
43.6.4. Flat directory repository
If you want to use a (flat) filesystem directory as a repository, simply type:
Example 43.30. Flat repository resolver
build.gradle
repositories { flatDir {
dirs 'lib'
}
flatDir {
dirs 'lib1', 'lib2'
}
}
This adds repositories which look into one or more directories for finding dependencies. If you only work with flat directory resolvers you don't need to set all attributes of a dependency. See Section 43.4.8, “Optional attributes”
43.6.5. Ivy repositories
To use an Ivy repository with a standard layout:
Example 43.31. Ivy repository
build.gradle
repositories { ivy {
url "http://repo.mycompany.com/repo" layout "maven"
}
}
See IvyArtifactRepository for details.
43.6.5.1. Defining custom patterns for an Ivy repository
To define an Ivy repository with a non-standard layout, you can define a pattern layout for the repository:
Page 233 of 343
Example 43.32. Ivy repository with pattern layout
build.gradle
repositories { ivy {
url "http://repo.mycompany.com/repo" layout 'pattern', {
artifact "[module]/[revision]/[artifact].[ext]" ivy "[module]/[revision]/ivy.xml"
}
}
}
43.6.5.2. Defining different artifact and ivy file locations for an Ivy repository
To define an Ivy repository which fetches ivy files and artifacts from different locations, you can explicitly define complete URL patterns for artifacts and ivy files:
Example 43.33. Ivy repository with custom patterns
build.gradle
repositories { ivy {
artifactPattern "http://repo.mycompany.com/3rd-party-artifacts/[organi artifactPattern "http://repo.mycompany.com/company-artifacts/[organisa ivyPattern "http://repo.mycompany.com/ivy-files/[organisation]/[module
}
}
43.6.5.3. Accessing password protected Ivy repositories
To access an Ivy repository which uses basic authentication, you specify the username and password to use when you define the repository:
Example 43.34. Ivy repository
build.gradle
repositories { ivy {
credentials { username 'user'
password 'password'
}
artifactPattern "http://repo.mycompany.com/[organisation]/[module]/[re
}
}
43.6.6. Working with repositories
To access a repository:
Page 234 of 343
Example 43.35. Accessing a repository
build.gradle
println repositories.localRepository.name println repositories['localRepository'].name
To configure a repository:
Example 43.36. Configuration of a repository
build.gradle
repositories { flatDir {
name 'localRepository'
}
}
repositories { localRepository {
dirs 'lib'
}
}
repositories.localRepository { dirs 'lib'
}
43.6.7. More about Ivy resolvers
Gradle, thanks to Ivy under its hood, is extremely flexible regarding repositories:
There are many options for the protocol to communicate with the repository (e.g. filesystem, http, ssh, ...)
Each repository can have its own layout.
Let's say, you declare a dependency on thejunit:junit:3.8.2 library. Now how does Gradle find it in the repositories? Somehow the dependency information has to be mapped to a path. In contrast to Maven, where this path is fixed, with Gradle you can define a pattern that defines what the path will look like. Here are some examples:
//Maven2 layout (if a repository is marked as Maven2 compatible, the organiza someroot/[organisation]/[module]/[revision]/[module]-[revision].[ext]
//Typical layout for an ivy repository (the organization is not split into su someroot/[organisation]/[module]/[revision]/[type]s/[artifact].[ext]
//Simple layout (the organization is not used, no nested folders.) someroot/[artifact]-[revision].[ext]
To add any kind of repository (you can pretty easy write your own ones) you can do:
Page 235 of 343