本文翻译所在分支： 。
更好的阅读体验请访问：
最新完成的完整翻译请查看2.0版本：
关于我对的翻译，以上的项目及http://gradledoc.githang.com 上的文档为准。如发现翻译有误的地方，将首先在以上两个地方更新。因时间精力问题，博客中发表的译文基本不会同步修改。
本章主要介绍 Gradle 依赖管理的一些基础知识。
This chapter introduces some of the basics of dependency management in Gradle.
通俗来讲，依赖管理由两部分组成。首先，Gradle 需要知道构建或运行你的项目所需要的东西，以便找到它们。 我们把这些传入的文件称为这个项目的 依赖。其次，Gradle 需要构建并且上传你的项目所产生的东西，我们把这些输出的文件称为项目的 发布物。下面详细介绍这两部分：
Very roughly, dependency management is made up of two pieces. Firstly, Gradle needs to know about the things that your project needs to build or run, in order to find them. We call these incoming files the dependencies of the project. Secondly, Gradle needs to build and upload the things that your project produces. We call these outgoing files the publications of the project. Let's look at these two pieces in more detail:
大部分项目都不是完全独立的，它们需要其他项目所构建的一些文件来编译或测试等等。例如，如果我想在我的项目中使用Hibernate，我需要在编译代码时把一些 Hibernate 的 jar 文件包含到类路径中。如果要运行测试，可能还需要把一些其他的 jar 包包含到测试类路径中，比如特定的 JDBC 驱动或者是 Ehcache jar 文件。
Most projects are not completely self-contained. They need files built by other projects in order to be compiled or tested and so on. For example, in order to use Hibernate in my project, I need to include some Hibernate jars in the classpath when I compile my source. To run my tests, I might also need to include some additional jars in the test classpath, such as a particular JDBC driver or the Ehcache jars.
请注意，这个功能相对于 Ant 提供了一个重要的优势。使用 Ant，您只能指定要加载的特定 jar 的绝对或相对路径。而通过 Gradle，您只需声明依赖的“名称”，其他层会确定从何处获取这些依赖项。您可以通过添加 Apache Ivy 从 Ant 获得类似的行为，但 Gradle 对此实现得更好。
Note that this feature provides a major advantage over Ant. With Ant, you only have the ability to specify absolute or relative paths to specific jars to load. With Gradle, you simply declare the “names” of your dependencies, and other layers determine where to get those dependencies from. You can get similar behavior from Ant by adding Apache Ivy, but Gradle does it better.
通常一个项目的依赖还会有它们自己本身的依赖。例如 Hibernate 核心类库在运行的时候就依赖于一些其他的类库。因此，当 Gradle运行你的项目的测试用例时，它也需要找到这些依赖并使其可用。我们把这个过程称为 传递依赖。
Often, the dependencies of a project will themselves have dependencies. For example, Hibernate core requires several other libraries to be present on the classpath with it runs. So, when Gradle runs the tests for your project, it also needs to find these dependencies and make them available. We call these transitive dependencies.
大多数项目的主要目的是构建一些在项目之外使用的文件。例如，如果你的项目是要生成一个 Java 库，你需要构建出一个 jar 文件，可能还需要一个源 jar 文件以及文档，然后把它们发布出去。
The main purpose of most projects is to build some files that are to be used outside the project. For example, if your project produces a Java library, you need to build a jar, and maybe a source jar and some documentation, and publish them somewhere.
我们来看一下一些依赖声明。下面是一个基本的构建脚本：
Let's look at some dependency declarations. Here's a basic build script:
示例 7.1. 声明依赖 - Example 7.1. Declaring dependencies
build.gradle
apply plugin: 'java'
repositories {
mavenCentral()
}
dependencies {
compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'
testCompile group: 'junit', name: 'junit', version: '4.+'
}
这里做了些什么？这个构建脚本说明了关于项目的一些事情。首先，它指出，Hibernate core 3.6.7.Final 是编项目的生产源代码所必需的。同时也暗指了，运行时还需要使用 Hibernate core 及其依赖。构建脚本还指出，编译项目的测试时需要4.0或以上的 junit。它还告诉 Gradle 在 Maven 中央存储库中查找所需的任何依赖。以下各节内容会进行详细介绍。
What's going on here? This build script says a few things about the project. Firstly, it states that Hibernate core 3.6.7.Final is required to compile the project's production source. By implication, Hibernate core and its dependencies are also required at runtime. The build script also states that any junit >= 4.0 is required to compile the project's tests. It also tells Gradle to look in the Maven central repository for any dependencies that are required. The following sections go into the details.
在Gradle中依赖会被分组到配置中。配置只是一组命名的依赖，我们会把它们称为依赖配置。您可以使用它们来声明项目的外部依赖。我们稍后会看到，它们也被用来声明你的项目的发布物。
In Gradle dependencies are grouped into configurations. A configuration is simply a named set of dependencies. We will refer to them as dependency configurations. You can use them to declare the external dependencies of your project. As we will see later, they are also used to declare the publications of your project.
Java 插件定义了许多标准配置。这些配置代表了 Java 插件使用的类路径。有些列在下面，你也可以在了解到更多详细内容。
The Java plugin defines a number of standard configurations. These configurations represent the classpaths that the Java plugin uses. Some are listed below, and you can find more details in .
compile
编译项目的生产源码所需的依赖。
The dependencies required to compile the production source of the project.
runtime
运行时生产类所需的依赖。默认情况下，也包括了编译时依赖。
The dependencies required by the production classes at runtime. By default, also includes the compile time dependencies.
testCompile
编译项目测试源码所需的依赖。默认情况下，还包括了所编译的生产类和编译时依赖。
The dependencies required to compile the test source of the project. By default, also includes the compiled production classes and the compile time dependencies.
testRuntime
运行测试所需的依赖。默认情况下，还包括编译，运行时及测试编译的依赖。
The dependencies required to run the tests. By default, also includes the compile, runtime and test compile dependencies.
各种插件添加了更多的标准配置。你也可以定义一些自定义配置以在构建中使用。有关定义和定制依赖配置的详细内容，请参见。
Various plugins add further standard configurations. You can also define your own custom configurations to use in your build. Please see for the details of defining and customizing dependency configurations.
要定义外部依赖，你需要把一个依赖添加到依赖配置中：
To define an external dependency, you add it to a dependency configuration:
示例7.2. 外部依赖的定义 - Example 7.2. Definition of an external dependency
build.gradle
dependencies {
compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'
}
一个外部依赖使用group, name 和 version 属性来定义。根据你所使用的仓库类型不同， group 和 version 可能是可选的。
An external dependency is identified using group, name and version attributes. Depending on which kind of repository you are using, group and version may be optional.
用于声明外部依赖的快捷形式看起来像：“group:name:version
The shortcut form for declaring external dependencies looks like “group:name:version
示例7.3. 外部依赖的快捷定义 - Example 7.3. Shortcut definition of an external dependency
build.gradle
dependencies {
compile 'org.hibernate:hibernate-core:3.6.7.Final'
}
要了解有关定义和使用依赖的更多信息，请查看《》。
To find out more about defining and working with dependencies, have a look at .
Gradle是如何找到外部依赖的文件的呢？它通过在一个仓库去查找它们。一个仓库实际上只是一组按group，name和version组织的文件。Gradle支持多种不同的仓库格式，例如 Maven 和 Ivy；并支持多种访问仓库的方法，例如使用本地文件系统或 HTTP。
How does Gradle find the files for external dependencies? Gradle looks for them in a repository. A repository is really just a collection of files, organized by group, name and version. Gradle understands several different repository formats, such as Maven and Ivy, and several different ways of accessing the repository, such as using the local file system or HTTP.
默认情况下，Gradle 没有定义任何仓库。需要你至少去定义一个，然后才能使用外部依赖。其中一个选项是使用 Maven 中央仓库：
By default, Gradle does not define any repositories. You need to define at least one before you can use external dependencies. One option is use the Maven central repository:
示例7.4. 使用 Maven 中央仓库 - Example 7.4. Usage of Maven central repository
build.gradle
repositories {
mavenCentral()
}
或 Bintray 的 JCenter：
Or Bintray's JCenter:
示例 7.5. 使用 JCenter 仓库 - Example 7.5. Usage of JCenter repository
build.gradle
repositories {
jcenter()
}
或任何一个其他远程 Maven 仓库：
Or a any other remote Maven repository:
示例7.6. 使用远程的 Maven 仓库 - Example 7.6. Usage of a remote Maven repository
build.gradle
repositories {
maven {
url "http://repo.mycompany.com/maven2"
}
}
或者是一个远程的 Ivy 仓库：
Or a remote Ivy repository:
build.gradle
repositories {
ivy {
url "http://repo.mycompany.com/repo"
}
}
你还可以在本地文件系统上部署一个仓库，它对于 Maven 和 Ivy 仓库都支持。
You can also have repositories on the local file system. This works for both Maven and Ivy repositories.
build.gradle
repositories {
ivy {
// URL can refer to a local directory
url "../local-repo"
}
}
一个项目可以有多个仓库。 Gradle 将按照指定的顺序在每个仓库中查找依赖，并在找到包含了所请求模块的第一个仓库后停止。
A project can have multiple repositories. Gradle will look for a dependency in each repository in the order they are specified, stopping at the first repository that contains the requested module.
要了解有关定义和使用仓库的更多信息，请查看《》。
To find out more about defining and working with repositories, have a look at .
依赖配置也用于发布文件。[]我们称这些文件为发布构件，通常也叫做构件。
Dependency configurations are also used to publish files.[] We call these files publication artifacts, or usually just artifacts.
插件对定义项目的构件提供了非常好的支持，所以通常无需再做其他事情来告诉 Gradle 需要发布什么。但是，你需要告诉 Gradle 发布到哪里。这就需要在 uploadArchives 任务中添加一个仓库。以下是发布到远程 Ivy 仓库的一个示例：
The plugins do a pretty good job of defining the artifacts of a project, so you usually don't need to do anything special to tell Gradle what needs to be published. However, you do need to tell Gradle where to publish the artifacts. You do this by attaching repositories to the uploadArchives task. Here's an example of publishing to a remote Ivy repository:
示例7.9. 发布到 Ivy 仓库 - Example 7.9. Publishing to an Ivy repository
build.gradle
uploadArchives {
repositories {
ivy {
credentials {
username "username"
password "pw"
}
url "http://repo.mycompany.com"
}
}
}
现在，当你运行gradle uploadArchives 后，Gradle 将会构建你的 Jar 包，以及生成 ivy.xml 并且一起上传。
Now, when you run gradle uploadArchives, Gradle will build and upload your Jar. Gradle will also generate and upload an ivy.xml as well.
你也可以发布到 Maven 仓库，语法略有不同。[]请注意，你需要应用 Maven 插件才能发布到 Maven 仓库。在这种情况下，Gradle 会生成 pom.xml 并上传。
You can also publish to Maven repositories. The syntax is slightly different.[] Note that you also need to apply the Maven plugin in order to publish to a Maven repository. when this is in place, Gradle will generate and upload a pom.xml.
示例7.10. 发布到 Maven 仓库 - Example 7.10. Publishing to a Maven repository
build.gradle
apply plugin: 'maven'
uploadArchives {
repositories {
mavenDeployer {
repository(url: "file://localhost/tmp/myRepo/")
}
}
}
要了解有关发布的更多信息，请查看《》。
To find out more about publication, have a look at .
有关依赖解析的所有细节，请参阅《》；而关于构件发布则请参阅《》。
For all the details of dependency resolution, see , and for artifact publication see .
如果对这里提到的 DSL 元素感兴趣，请查看 ， 和 。
If you are interested in the DSL elements mentioned here, have a look at , and .
不然，就继续其他吧。
Otherwise, continue on to some of the other .
[] 关于这点，我们认为会让人感到很困惑，因此我们正在逐渐梳理 Gradle DSL 中的这两个概念。
[] We think this is confusing, and we are gradually teasing apart the two concepts in the Gradle DSL.
[] 我们正在努力统一从 Maven 仓库解析依赖以及向其发布的语法。
[] We are working to make the syntax consistent for resolving from and publishing to Maven repositories.