This chapter introduces some of the basics of dependency management in 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:
おおざっぱに言って、依存関係の管理とは二つの部分に分けられます。まず、Gradleは、あなたのプロジェクトをビルドしたり実行したりするのに必要なファイルが何かを判定し、それらを見つけてこなければなりません。これらの入力ファイルを、プロジェクトの依存関係と呼びます。 次に、Gradleはあなたのプロジェクトをビルドし、生成されたものをアップロードする必要があります。これらの出力ファイルを、プロジェクトの公開物と呼びます。
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.
ほとんどのプロジェクトは、完全に自己完結しているわけではありません。コンパイル、テスト、その他諸々のために、他のプロジェクトがビルドするファイルを必要とするものです。例えば、Hibernateを自分のプロジェクトで使うために、ソースコードのコンパイル時にHibernateのjarファイルをいくつか取り込む、といった具合です。テストをするためには、さらにいくつかのjarファイル、JDBCドライバやEhcacheのjarをテスト時クラスパスに追加する必要があるかもしれません。
These incoming files form the dependencies of the project. Gradle allows you to tell it what the dependencies of your project are, so that it can take care of finding these dependencies, and making them available in your build. The dependencies might need to be downloaded from a remote Maven or Ivy repository, or located in a local directory, or may need to be built by another project in the same multi-project build. We call this process dependency resolution.
これらの入力ファイルは、プロジェクトの依存関係から読み込まれます。 Gradleにプロジェクトの依存関係を教えて、プロジェクトが依存しているファイルを見つけたり、ビルド時にそれらを使えるようにできます。 依存ファイルは、リモートのMavenやIvyのリポジトリからダウンロードされるかもしれませんし、ローカルのディレクトリにあるかもしれません。また、マルチプロジェクトの場合、別のプロジェクトにビルドさせる必要があることもあります。
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.
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.
また、依存しているファイルが、それ自身の依存関係を持っていることが多々あります。例えば、Hibernateコアは、実行時にいくつかの別のライブラリをクラスパスに含めなければなりません。なので、Gradleがあなたのプロジェクトのテストを走らせるときには、それらの依存関係も見つけてきて、使用できるようにしなければならないのです。これを、推移的な依存関係と呼びます。
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.
ほとんどのプロジェクトは、ファイルを作成し、それらをプロジェクトの外部で使うということを主な目的としています。 例えば、もしあなたのプロジェクトがJavaライブラリを作成するものならば、あなたはjarを作成し、ときにはソースjarやドキュメントも作成し、どこかにそれらを公開しなければなりません。
These outgoing files form the publications of the project. Gradle also takes care of this important work for you. You declare the publications of your project, and Gradle take care of building them and publishing them somewhere. Exactly what “publishing” means depends on what you want to do. You might want to copy the files to a local directory, or upload them to a remote Maven or Ivy repository. Or you might use the files in another project in the same multi-project build. We call this process publication.
ファイルの公開は、プロジェクトの公開設定から読み込まれて行われます。Gradleは、この重要な仕事も引き受けてくれます。プロジェクトが公開するファイルを宣言すれば、Gradleがそれらをビルドし、任意の場所へ公開します。 「公開する」ということの正確な意味は、何をしたいのかによって異なります。ローカルディレクトリにファイルをコピーしたいかもしれませんし、リモートのMavenやIvyのリポジトリにアップロードしたいかもしれません。また、マルチプロジェクトの場合、別プロジェクトからそのファイルを使いたいという場合もあります。 これらの処理を、公開と呼んでいます。
Let's look at some dependency declarations. Here's a basic build script:
さて、では依存関係の宣言についていくつか見ていきましょう。ここに、ある基本的なビルドスクリプトがあります。
例8.1 依存関係の宣言
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.+' }
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.
一体、何が起きるでしょうか。このビルドスクリプトにはそれほど多くの情報はありません。まず、このプロジェクトはソースコードをコンパイルするためにHibernate core 3.6.7を使用すると言っています。それはすなわち、実行時にHibernate coreとその依存関係が必要になるということでもあります。 このスクリプトはまた、バージョン4.0以上のJUnitのどれかを、プロジェクトのテストをコンパイルするのに必要とするとも言っています。さらに、Gradleに、全ての依存関係を見つけるのにMavenのセントラルリポジトリを探すように指示しています。次の節で、それぞれの詳細について見ていきましょう。
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.
Gradleでは、依存関係は、コンフィグレーションによってグループ化されます。コンフィグレーションとは、単なる名前の付いた依存関係の集まりです。コンフィグレーションは依存関係設定として参照されます。プロジェクトが外部に依存しているものを宣言するのに使われ、また後で見るように、プロジェクトが外部に公開するものを宣言するためにも使用されます。
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 表23.5「Javaプラグイン - 依存関係のコンフィギュレーションJava plugin - dependency configurations」.
Javaプラグインは、いくつかの標準コンフィグレーションを定義します。これらのコンフィグレーションは、Javaプラグインが使用するクラスパスを表すものです。いくつかを以下にリストしました。詳細については、表23.5「Javaプラグイン - 依存関係のコンフィギュレーションJava plugin - dependency configurations」を参照してください。
The dependencies required to compile the production source of the project.
プロジェクトのプロダクトコードをコンパイルするのに必要な依存関係
The dependencies required by the production classes at runtime. By default, also includes the compile time dependencies.
プロダクトのクラスを実行するときに必要になる依存関係。デフォルトで、コンパイル時の依存関係もここに含まれる。
The dependencies required to compile the test source of the project. By default, also includes the compiled production classes and the compile time dependencies.
プロジェクトのテストコードをコンパイルするのに必要な依存関係。デフォルトで、コンパイルされたプロダクトクラスと、コンパイル時の依存関係も含まれる。
The dependencies required to run the tests. By default, also includes the compile, runtime and test compile dependencies.
テストを実行するのに必要な依存関係。デフォルトで、compile、runtime、testCompileの各依存関係もここに含まれる。
Various plugins add further standard configurations. You can also define your own custom configurations to use in your build. Please see 「依存関係のコンフィギュレーション Dependency configurations」 for the details of defining and customizing dependency configurations.
多くのプラグインが、このような標準コンフィグレーションを追加します。また、自分のビルドに使うためのカスタムコンフィギュレーションを独自に定義することもできます。依存関係のコンフィグレーション定義やカスタマイズの詳細については、「依存関係のコンフィギュレーション Dependency configurations」を参照してください。
There are various types of dependencies that you can declare. One such type is an external dependency. This a dependency on some files built outside the current build, and stored in a repository of some kind, such as Maven central, or a corporate Maven or Ivy repository, or a directory in the local file system.
定義できる依存関係には、さまざまなタイプがあります。そのうちの一つが、外部依存関係です。これは、今のビルドとは別に作られ、MavenセントラルリポジトリやIvyリポジトリ、ローカルファイルシステムなどに保存されているファイルへの依存関係です。
To define an external dependency, you add it to a dependency configuration:
外部依存関係を定義するには、それを依存関係のコンフィグレーションに追加します。
例8.2 外部依存関係の定義
build.gradle
dependencies { compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final' }
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
属性を用いて定義します。
使用しているリポジトリの種類によっては、group
属性とversion
属性はオプショナルになるかもしれません。
The shortcut form for declaring external dependencies looks like “
”.
group
:name
:version
There is a shortcut form for declaring external dependencies, which uses a string of the form "
.
group
:name
:version
"
外部依存関係を定義するときは、ショートカット形式を使うこともできます。"
という文字列を使う形式です。
group
:name
:version
"
例8.3 外部依存関係定義のショートカット形式
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 「依存関係の定義方法 How to declare your dependencies」.
依存関係を定義して取り扱う方法について、詳しくは「依存関係の定義方法 How to declare your dependencies」を見てください。
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は、どうやって外部依存関係を見つけるのでしょうか? Gradleは、それらをリポジトリから探します。リポジトリの実体は、ただのファイルの集合です。それらのファイルは、グループ
、名前
、そしてバージョン
によって分類されています。Gradleは、MavenやIvyなど、様々なリポジトリ形式に対応できます。また、ローカルファイルシステムやHTTPなど、リポジトリにアクセスするための手段についても様々なものを使うことができます。
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:
デフォルトでは、Gradleはリポジトリを一切定義していません。外部依存関係を使うには、少なくとも一つのリポジトリを定義する必要があります。 選択肢の一つは、Mavenのセントラルリポジトリを使うことです。
Or a remote Maven repository:
または、別のMavenリモートリポジトリを使います。
Or a remote Ivy repository:
または、リモートのIvyリポジトリを使います。
You can also have repositories on the local file system. This works for both Maven and Ivy repositories.
さらに、ローカルファイルシステム上にリポジトリを持つこともできます。これは、Maven、Ivy双方のリポジトリ形式で動作します。
例8.7 ローカルのIvyディレクトリを使う
build.gradle
repositories { ivy { // URL can refer to a local directory url "../local-repo" } }
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.
一つのプロジェクトが、複数のリポジトリを持つことができます。Gradleは、それぞれのリポジトリを、指定された順序で順に探しに行きます。要求されたモジュールが含まれる、最初のリポジトリを見つけるまで走査を続けます。
To find out more about defining and working with repositories, have a look at 「リポジトリ Repositories」.
リポジトリを定義し、取り扱う方法について、詳しくは「リポジトリ Repositories」を参照してください。
Dependency configurations are also used to publish files.[5] We call these files publication artifacts, or usually just artifacts.
依存関係のコンフィグレーションは、ファイルを公開するのにも使用します。[6] これらのファイルを、公開アーティファクト、大体は単にアーティファクトと呼びます。
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:
プラグインが非常に適切にプロジェクトのアーティファクトを定義してくれるので、何を公開したいかGradleに教えるのに、特別何かする必要はほとんどの場合ありません。ただ、どこに公開したいかはGradleに教えてやる必要があります。これは、リポジトリをuploadArchives
タスクに結びつけることで行います。次のコードは、リモートのIvyリポジトリに公開する例です。
例8.8 Ivyリポジトリに公開する
build.gradle
uploadArchives { repositories { ivy { credentials { username "username" password "pw" } url "http://repo.mycompany.com" } } }
Now, when you run gradle uploadArchives
, Gradle will build and upload your Jar.
Gradle will also generate and upload an ivy.xml
as well.
これでgradle uploadArchives
を走らせれば、Gradleがjarをビルドしてアップロードしてくれます。
さらに、ivy.xml
も生成されてアップロードされます。
You can also publish to Maven repositories. The syntax is slightly different.[7]
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
.
Mavenリポジトリに公開することもできますが、その文法はすこし異なります[8]。
また、Mavenリポジトリへ公開するには、Mavenプラグインを使う必要もあるので注意してください。この場合、Gradleはpom.xml
も生成してアップロードします。
例8.9 Mavenリポジトリへの公開
build.gradle
apply plugin: 'maven' uploadArchives { repositories { mavenDeployer { repository(url: "file://localhost/tmp/myRepo/") } } }
To find out more about publication, have a look at 52章アーティファクトの公開 .
アーティファクトの公開について、詳しくは52章アーティファクトの公開 をご参照ください。
For all the details of dependency resolution, see 51章依存関係の管理 , and for artifact publication see 52章アーティファクトの公開 .
依存関係解決については、51章依存関係の管理 に全て詳細に載っています。そして、アーティファクトの公開については52章アーティファクトの公開 に載っています。
If you are interested in the DSL elements mentioned here, have a look at Project.configurations{}
,
Project.repositories{}
and Project.dependencies{}
.
本章で使ったDSLに興味があるのであれば、Project.configurations{}
やProject.repositories{}
、Project.dependencies{}
を見てください。
Otherwise, continue on to some of the other tutorials.
それ以外の場合は、チュートリアルから他のチュートリアルを進めてください。
[5] We think this is confusing, and we are gradually teasing apart the two concepts in the Gradle DSL.
[6] 私たちは、これは混乱の元になると考えています。そのため、GradleのDSLでは、段階的に二つに概念に分けていくつもりです。
[7] We are working to make the syntax consistent for resolving from and publishing to Maven repositories.
[8] 私たちは、Mavenリポジトリからの取得とMavenリポジトリへの公開を一貫した文法で行えるよう作業しているところです。