Gadle can resolve dependencies from one or many repositories based on Maven, Ivy or flat directory formats. Check out the full reference on all types of repositories for more information.
Declaring a publicly-available repository
Organizations building software may want to leverage public binary repositories to download and consume open source dependencies. Popular public repositories include Maven Central, Bintray JCenter and the Google Android repository. Gradle provides built-in shorthand notations for these widely-used repositories.
Figure 1. Declaring a repository with the help of shorthand notations
Under the covers Gradle resolves dependencies from the respective URL of the public repository defined by the shorthand notation. All shorthand notations are available via the RepositoryHandler API. Alternatively, you can spell out the URL of the repository for more fine-grained control.
Maven Central repository
Maven Central is a popular repository hosting open source libraries for consumption by Java projects.
To declare the Maven Central repository for your build app this to your script:
JCenter Maven repository
Bintray's JCenter is and up-to-date collection of all popular Maven OSS(Open Source Software) artifacts, including artifacts published directly to Bintray.
To declare the JCenter Maven repository add this to your build script:
Google Maven repository
The Google repository hosts Android-specific artifacts including the Android SDK. For usage examples, see the relevant Adroid documentations.
To declare the Google Maven repository add this to your build script:
Declaring a custom repository by URL
Most enterprise projects set up a binary repository available only within an intranet. In-house repositories enable teams to publish internal binaries, setup user management and security measure and ensure uptime and availability. Specifying a custom URL is also helpful if you want to declare a less popular, but publicly-available repository.
Repositories with custom URLs can be specified as Maven or Ivy repositories by calling the corresponding methods available on the RepositoryHandler API. Gradle supports other protocols than http or https as part of the custom URL e.g. file, sftp or s3. For a full coverage see the section on supported repository types.
You can also define your own repository layout by using ivy{} repositories as they are very flexible in term of how module are organised in a repository.
Declaring multiple repositories
You can define more than one repository for resolving dependencies. Declaring multiple repositories is helpful if some dependencies are only available in one repository but not the other. You can mix any type of respository described in the reference section.
This example demonstrates how to declare various names and custom URL repositories for a project:
The order of declaration determines how Gradle will check for dependencies at runtime. If Gradle finds a moudle descriptor in a particular repository, it will attempt to download all of the artifacts for that module from the same repository. You can learn more about inner workings of dependency downloads.
Strict limitation to declared repositories
Maven POM metadata can reference additional repositories. These will be ignored by Gradle, which will only use the repositories declared in the build itself.
This is a reproducibility safe-guard but also a security protection. Without it, an updated version of a dependency could pull artifacts from anywhere into your build.
Supported repository types
Gradle supports a wide range of sources for dependencies, both in terms of format and in terms of connectivity. You may resolve dependencies from:
•
with different connectivity
◦
authenticated repositories
◦
a wide variety of remote protocols such as HTTPS, SFTP, AWS S3 and Google Cloud Storage
Flat directory repository
Some projects might prefer to store dependencies on a shared drive or as part of the project source code instead of a binary repository product. If you want to use a (flat) filesystem directory as a repository, simply type:
This adds repositories which look into one or more directories for finding depedencies. This type of repository does not support any mete-data formats like Ivy XML or Maven POM files. Instead, Gradle will dynamically gernerate a module decriptor (without any dependency information) based on the presence of artifacts.
As Gradle prefers to use modules whose descriptor has been created from real meta-data rather than being generated, flat directory repositories cannot be used to override artifacts with real meta-data from other repositories declared in the build.
If you only work with flat directory repositories you don't need to set all attributes of a dependency.
Local repositories
The following sections describe repositories format, Maven or Ivy. These can be declared as local repositories, using a local filesystem path to access them.
The difference with the flat directory repository is that they do respect a format and contain metadata.
When such a repository is configured, Gradle totally bypasses its dependency cache for it as there can be no guarantee that content may not change between executions(?). Because of that limitation, they can have a performance impact.
They also make build reproducibility much harder to achieve and their use should be limited to tinkering or prototyping(?).
Maven repositories
Many organizations host dependencies in an in-house Maven repository only accessible within the company's network. Gradle can declare Maven repositories by URL.
For adding a custom Maven repository you can do:
Setting up composite Maven repositories
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:
Gradle will look at the base url location for the POM and the JAR. If the JAR can't be found there, the extra artifactUrls are used to look for JARs.
Accessing authenticated Maven repositories
You can specify credentials for Maven repositories secured by different type of authentication.
Local Maven repository
Gradle can consume dependencies available in the local Maven repository. Declaring this repository is benefical for teams that publish to the local Maven repository with one project and consume the artifacts by Gradle in another project.
Gradle stores resolved dependencies in its own cache. A build does not need to declare local Maven repository even it you resolve dependencies from a Maven-based, remote repository.
Before adding Maven local as a respository, you should make sure this is really required.
To declare the local Maven cache as a repository add this to your build scipt:
Gradle uses the same logic as Maven to identify the location of your local Maven cache. If a local repository location is defined in a settings.xml, this location will be used. The settings.xml in USER_HOME/.m2 takes precedence over the settings.xml in M2_HOME/conf. If no settings.xml is available, Gradle uses the default location USER_HOME/.m2/repository.
