转自：https://docs.gradle.org/4.4.1/userguide/dependency_management.html#sec:repositories

25.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:

Table 25.2. Repository types

Maven central repository

A pre-configured repository that looks for dependencies in Maven Central.

Maven JCenter repository

A pre-configured repository that looks for dependencies in Bintray’s JCenter.

Maven Google repository

A pre-configured repository that looks for dependencies in Google’s Maven repository.

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.

25.6.1. Maven central repository

To add the central Maven 2 repository (https://repo.maven.apache.org/maven2) simply add this to your build script:

* Example 25.25. Adding central Maven repository *
build.gradle

repositories {
    mavenCentral()
}

Now Gradle will look for your dependencies in this repository.

25.6.2. Maven JCenter repository

Bintray’s JCenter is an up-to-date collection of all popular Maven OSS artifacts, including artifacts published directly to Bintray.

To add the JCenter Maven repository (https://jcenter.bintray.com) simply add this to your build script:
Example 25.26. Adding Bintray’s JCenter Maven repository

build.gradle

repositories { 

    jcenter() 

}

Now Gradle will look for your dependencies in the JCenter repository. jcenter() uses HTTPS to connect to the repository. If you want to use HTTP you can configure jcenter():

Example 25.27. Using Bintrays’s JCenter with HTTP

build.gradle

repositories { 

    jcenter { 

        url “http://jcenter.bintray.com/” 

    } 

}

25.6.3. Maven Google repository

The Google repository hosts Android-specific artifacts including the Android SDK. For usage examples please the relevant documentation.

To add the Google Maven repository (https://dl.google.com/dl/android/maven2/) simply add this to your build script:

Example 25.28. Adding Google Maven repository

build.gradle

repositories { 

    google() 

}

25.6.4. Local Maven repository

To use the local Maven cache as a repository you can do:

Example 25.29. Adding the local Maven cache as a repository

build.gradle

repositories { 

    mavenLocal() 

} 

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 <span class="emphasis">_USER_HOME_</span>/.m2 takes precedence over the settings.xml in <span class="emphasis">_M2_HOME_</span>/conf. If no settings.xml is available, Gradle uses the default location <span class="emphasis">_USER_HOME_</span>/.m2/repository.

gradle.org/4.4.1/userguide/dependency_management.html#sub:maven_repo">25.6.5. Maven repositories

For adding a custom Maven repository you can do:

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:

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, the artifact URLs are used to look for JARs.

gradle.org/4.4.1/userguide/dependency_management.html#sec:accessing_password_protected_maven_repositories">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:

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.

gradle.org/4.4.1/userguide/dependency_management.html#sec:flat_dir_resolver">25.6.6. Flat directory repository

If you want to use a (flat) filesystem directory as a repository, simply type:

repositories {
    flatDir {
        dirs 'lib'
    }
    flatDir {
        dirs 'lib1', 'lib2'
    }
}

This adds repositories which look into one or more directories for finding dependencies. Note that this type of repository does not support any meta-data formats like Ivy XML or Maven POM files. Instead, Gradle will dynamically generate a module descriptor (without any dependency information) based on the presence of artifacts. However, 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. So, for example, if Gradle finds only jmxri-1.2.1.jar in a flat directory repository, but jmxri-1.2.1.pom in another repository that supports meta-data, it will use the second repository to provide the module. For the use case of overriding remote artifacts with local ones consider using an Ivy or Maven repository instead whose URL points to a local directory. If you only work with flat directory repositories you don’t need to set all attributes of a dependency. See Section 25.4.8, “Optional attributes”.

gradle.org/4.4.1/userguide/dependency_management.html#sec:ivy_repositories">25.6.7. Ivy repositories

gradle.org/4.4.1/userguide/dependency_management.html#sec:defining_an_ivy_repository_with_a_standard_layout">Defining an Ivy repository with a standard layout

Example 25.34. Ivy repository

repositories {
    ivy {
        url "http://repo.mycompany.com/repo"
    }
}

gradle.org/4.4.1/userguide/dependency_management.html#sec:defining_a_named_layout_for_an_ivy_repository">Defining a named layout for an Ivy repository

You can specify that your repository conforms to the Ivy or Maven default layout by using a named layout.

repositories {
    ivy {
        url "http://repo.mycompany.com/repo"
        layout "maven"
    }
}

Valid named layout values are 'gradle' (the default), 'maven', 'ivy' and 'pattern'. See IvyArtifactRepository.layout(java.lang.String, groovy.lang.Closure) in the API documentation for details of these named layouts.

gradle.org/4.4.1/userguide/dependency_management.html#sec:defining_custom_pattern_layout_for_an_ivy_repository">Defining custom pattern layout for an Ivy repository

To define an Ivy repository with a non-standard layout, you can define a ‘pattern’ layout for the repository:

repositories {
    ivy {
        url "http://repo.mycompany.com/repo"
        layout "pattern", {
            artifact "[module]/[revision]/[type]/[artifact].[ext]"
        }
    }
}

To define an Ivy repository which fetches Ivy files and artifacts from different locations, you can define separate patterns to use to locate the Ivy files and artifacts:

Each artifact or ivy specified for a repository adds an additional pattern to use. The patterns are used in the order that they are defined.

repositories {
    ivy {
        url "http://repo.mycompany.com/repo"
        layout "pattern", {
            artifact "3rd-party-artifacts/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"
            artifact "company-artifacts/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"
            ivy "ivy-files/[organisation]/[module]/[revision]/ivy.xml"
        }
    }
}

Optionally, a repository with pattern layout can have its ‘organisation’ part laid out in Maven style, with forward slashes replacing dots as separators. For example, the organisation my.company would then be represented as my/company.

repositories {
    ivy {
        url "http://repo.mycompany.com/repo"
        layout "pattern", {
            artifact "[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"
            m2compatible = true
        }
    }
}

gradle.org/4.4.1/userguide/dependency_management.html#sec:accessing_password_protected_ivy_repositories">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:

repositories {
    ivy {
        url 'http://repo.mycompany.com'
        credentials {
            username 'user'
            password 'password'
        }
    }
}

gradle.org/4.4.1/userguide/dependency_management.html#sub:supported_transport_protocols">25.6.8. Supported repository transport protocols

Maven and Ivy repositories support the use of various transport protocols. At the moment the following protocols are supported:

To define a repository use the repositories configuration block. Within the repositories closure, a Maven repository is declared with maven. An Ivy repository is declared with ivy. The transport protocol is part of the URL definition for a repository. The following build script demonstrates how to create a HTTP-based Maven and Ivy repository:

repositories {
    maven {
        url "http://repo.mycompany.com/maven2"
    }

    ivy {
        url "http://repo.mycompany.com/repo"
    }
}

If authentication is required for a repository, the relevant credentials can be provided. The following example shows how to provide username/password-based authentication for SFTP repositories:

repositories {
    maven {
        url "sftp://repo.mycompany.com:22/maven2"
        credentials {
            username 'user'
            password 'password'
        }
    }

    ivy {
        url "sftp://repo.mycompany.com:22/repo"
        credentials {
            username 'user'
            password 'password'
        }
    }
}

When using an AWS S3 backed repository you need to authenticate using AwsCredentials, providing access-key and a private-key. The following example shows how to declare a S3 backed repository and providing AWS credentials:

repositories {
    maven {
        url "s3://myCompanyBucket/maven2"
        credentials(AwsCredentials) {
            accessKey "someKey"
            secretKey "someSecret"
            // optional
            sessionToken "someSTSToken"
        }
    }

    ivy {
        url "s3://myCompanyBucket/ivyrepo"
        credentials(AwsCredentials) {
            accessKey "someKey"
            secretKey "someSecret"
            // optional
            sessionToken "someSTSToken"
        }
    }
}

You can also delegate all credentials to the AWS sdk by using the AwsImAuthentication. The following example shows how:

repositories {
    maven {
        url "s3://myCompanyBucket/maven2"
        authentication {
           awsIm(AwsImAuthentication) // load from EC2 role or env var
        }
    }

    ivy {
        url "s3://myCompanyBucket/ivyrepo"
        authentication {
           awsIm(AwsImAuthentication)
        }
    }
}

When using a Google Cloud Storage backed repository default application credentials will be used with no further configuration required:

repositories {
    maven {
        url "gcs://myCompanyBucket/maven2"
    }

    ivy {
        url "gcs://myCompanyBucket/ivyrepo"
    }
}

gradle.org/4.4.1/userguide/dependency_management.html#sub:s3_configuration_properties">S3 configuration properties

The following system properties can be used to configure the interactions with s3 repositories:

gradle.org/4.4.1/userguide/dependency_management.html#sub:s3_url_formats">S3 URL formats

S3 URL’s are ‘virtual-hosted-style’ and must be in the following format s3://<bucketName>[.<regionSpecificEndpoint>]/<s3Key>

e.g. s3://myBucket.s3.eu-central-1.amazonaws.com/maven/release

gradle.org/4.4.1/userguide/dependency_management.html#sub:s3_proxy_settings">S3 proxy settings

A proxy for S3 can be configured using the following system properties:

If the ‘org.gradle.s3.endpoint’ property has been specified with a http (not https) URI the following system proxy settings can be used:

gradle.org/4.4.1/userguide/dependency_management.html#s3_v4_signatures">AWS S3 V4 Signatures (AWS4-HMAC-SHA256)

Some of the AWS S3 regions (eu-central-1 - Frankfurt) require that all HTTP requests are signed in accordance with AWS’s signature version 4. It is recommended to specify S3 URL’s containing the region specific endpoint when using buckets that require V4 signatures. e.g. s3://somebucket.s3.eu-central-1.amazonaws.com/maven/release

gradle.org/4.4.1/userguide/dependency_management.html#sub:gcs_configuration_properties">Google Cloud Storage configuration properties

The following system properties can be used to configure the interactions with Google Cloud Storage repositories:

gradle.org/4.4.1/userguide/dependency_management.html#sub:gcs_url_formats">Google Cloud Storage URL formats

Google Cloud Storage URL’s are ‘virtual-hosted-style’ and must be in the following format gcs://<bucketName>/<objectKey>

e.g. gcs://myBucket/maven/release

gradle.org/4.4.1/userguide/dependency_management.html#sub:authentication_schemes">Configuring HTTP authentication schemes

When configuring a repository using HTTP or HTTPS transport protocols, multiple authentication schemes are available. By default, Gradle will attempt to use all schemes that are supported by the Apache HttpClient library, documented here. In some cases, it may be preferable to explicitly specify which authentication schemes should be used when exchanging credentials with a remote server. When explicitly declared, only those schemes are used when authenticating to a remote repository. The following example show how to configure a repository to use only digest authentication:

repositories {
    maven {
        url 'https://repo.mycompany.com/maven2'
        credentials {
            username 'user'
            password 'password'
        }
        authentication {
            digest(DigestAuthentication)
        }
    }
}

Currently supported authentication schemes are:

gradle.org/4.4.1/userguide/dependency_management.html#sub:preemptive_authentication">Using preemptive authentication

Gradle’s default behavior is to only submit credentials when a server responds with an authentication challenge in the form of a HTTP 401 response. In some cases, the server will respond with a different code (ex. for repositories hosted on GitHub a 404 is returned) causing dependency resolution to fail. To get around this behavior, credentials may be sent to the server preemptively. To enable preemptive authentication simply configure your repository to explicitly use the BasicAuthentication scheme:

repositories {
    maven {
        url 'https://repo.mycompany.com/maven2'
        credentials {
            username 'user'
            password 'password'
        }
        authentication {
            basic(BasicAuthentication)
        }
    }
}

gradle.org/4.4.1/userguide/dependency_management.html#sec:working_with_repositories">25.6.9. Working with repositories

To access a repository:

println repositories.localRepository.name
println repositories['localRepository'].name

To configure a repository:

repositories {
    flatDir {
        name 'localRepository'
    }
}
repositories {
    localRepository {
        dirs 'lib'
    }
}
repositories.localRepository {
    dirs 'lib'
}

gradle.org/4.4.1/userguide/dependency_management.html#sub:more_about_ivy_resolvers">25.6.10. More about Ivy resolvers

Gradle is extremely flexible regarding repositories:

Let’s say, you declare a dependency on the junit: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:^[12]

// Maven2 layout (if a repository is marked as Maven2 compatible, the organization (group) is split into subfolders according to the dots.)
someroot/[organisation]/[module]/[revision]/[module]-[revision].[ext]

// Typical layout for an Ivy repository (the organization is not split into subfolder)
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:

repositories {
    ivy {
        ivyPattern "$projectDir/repo/[organisation]/[module]-ivy-[revision].xml"
        artifactPattern "$projectDir/repo/[organisation]/[module]-[revision](-[classifier]).[ext]"
    }
}

An overview of which Resolvers are offered by Ivy and thus also by Gradle can be found here. With Gradle you just don’t configure them via XML but directly via their API.