第52章 アーティファクトの公開

This chapter describes the original publishing mechanism available in Gradle 1.0: in Gradle 1.3 a new mechanism for publishing was introduced. While this new mechanism is incubating and not yet complete, it introduces some new concepts and features that do (and will) make Gradle publishing even more powerful.

この章は、Gradle1.0の段階で使用されている既存の公開システムについて書かれています。Gradle1.3からは、公開処理に新しい仕組みが導入されました。 この仕組みは現在試験的な段階にあり、まだ完成していませんが、Gradleの公開処理をより強力にする新しい概念、機能がいくつか取り入れられる予定です。

You can read about the new publishing plugins in Chapter 65, Ivy Publishing (new) and Chapter 66, Maven Publishing (new).

You can read about the new publishing plugins in Chapter 65, Ivy Publishing (new) and Chapter 66, Maven Publishing (new). Please try them out and give us feedback.

新しい公開プラグインについては、Chapter 65, Ivy Publishing (new)およびChapter 66, Maven Publishing (new)に詳しく記載されています。ぜひ試用してみてください。何かあればフィードバックしてもらえると幸いです。

52.1. はじめにIntroduction

This chapter is about how you declare the outgoing artifacts of your project, and how to work with them (e.g. upload them). We define the artifacts of the projects as the files the project provides to the outside world. This might be a library or a ZIP distribution or any other file. A project can publish as many artifacts as it wants.

この章では、プロジェクトが公開するアーティファクト(成果物)の定義方法と取り扱い(アップロードする方法など)について解説します。ここでいうプロジェクトのアーティファクトとは、外部の世界へ提供するファイルのことを指します。ライブラリやZIPの配布物かもしれませんし、なにか他のファイルかもしれません。一つのプロジェクトから、いくつでも好きなだけアーティファクトを公開することができます。

52.2. アーティファクトとコンフィギュレーションArtifacts and configurations

Like dependencies, artifacts are grouped by configurations. In fact, a configuration can contain both artifacts and dependencies at the same time.

依存関係と同じように、アーティファクトもコンフィギュレーションによってグループ化されます。実際、コンフィギュレーションにはアーティファクトと依存関係、両方を同時に含めることもできます。

For each configuration in your project, Gradle provides the tasks uploadConfigurationName and buildConfigurationName. [26] Execution of these tasks will build or upload the artifacts belonging to the respective configuration.

Gradleは、プロジェクト内のすべてのコンフィギュレーションに対して、uploadコンフィグレーション名 タスクとbuildコンフィグレーション名 タスクを提供します。 [27] これらのタスクを実行すると、対象のコンフィギュレーションに属しているアーティファクトをビルドしたり、アップロードしたりできます。

表23.5「Javaプラグイン - 依存関係のコンフィギュレーションJava plugin - dependency configurations shows the configurations added by the Java plugin. Two of the configurations are relevant for the usage with artifacts. The archives configuration is the standard configuration to assign your artifacts to. The Java plugin automatically assigns the default jar to this configuration. We will talk more about the runtime configuration in 「プロジェクトライブラリについての追記事項More about project libraries. As with dependencies, you can declare as many custom configurations as you like and assign artifacts to them.

表23.5「Javaプラグイン - 依存関係のコンフィギュレーションJava plugin - dependency configurationsに、Javaプラグインが追加するコンフィギュレーションの一覧を載せています。これらのうち、アーティファクトを使うに当たって関係があるものは次の二つです。archivesコンフィギュレーションは、プロジェクトのアーティファクトを含めるための標準のコンフィギュレーションです。Javaプラグインは、デフォルトのjarを自動的にこのコンフィギュレーションに追加します。「プロジェクトライブラリについての追記事項More about project librariesでは、runtimeコンフィギュレーションについて詳しく解説します。また、アーティファクトを追加するための独自コンフィギュレーションも、依存関係のコンフィギュレーションと同じようにいくつでも宣言して追加できます。

52.3. アーティファクトの宣言 Declaring artifacts

52.3.1. アーカイブタスク・アーティファクト Archive task artifacts

You can use an archive task to define an artifact:

アーカイブタスクを使ってアーティファクトを宣言できます。

例52.1 アーカイブタスクを使ってアーティファクトを宣言する

build.gradle

task myJar(type: Jar)

artifacts {
    archives myJar
}

It is important to note that the custom archives you are creating as part of your build are not automatically assigned to any configuration. You have to explicitly do this assignment.

重要なことですが、独自のアーカイブ作成をビルドに組み込んでも、そのアーカイブが自動的になんらかのコンフィグレーションに割り当てられるわけではないことに注目してください。割り当ては、明示的に行う必要があります。

52.3.2. ファイル・アーティファクト File artifacts

You can also use a file to define an artifact:

アーティファクトは、ファイルで宣言することもできます。

例52.2 アーティファクトをファイルで宣言する

build.gradle

def someFile = file('build/somefile.txt')

artifacts {
    archives someFile
}

Gradle will figure out the properties of the artifact based on the name of the file. You can customize these properties:

Gradleは、ファイル名を元にアーティファクトのプロパティを決定します。このプロパティは、以下のようにしてカスタマイズすることができます。

例52.3 アーティファクトのカスタマイズ

build.gradle

task myTask(type:  MyTaskType) {
    destFile = file('build/somefile.txt')
}

artifacts {
    archives(myTask.destFile) {
        name 'my-artifact'
        type 'text'
        builtBy myTask
    }
}

There is a map-based syntax for defining an artifact using a file. The map must include a file entry that defines the file. The map may include other artifact properties:

ファイルでアーティファクトを宣言する際には、Mapスタイルの文法を使うこともできます。そのMapにはファイルを宣言するfileエントリを含めなければなりません。そのほか、アーティファクトの各プロパティを含めることができます。

例52.4 ファイルでアーティファクトを宣言するMapスタイルの文法

build.gradle

task generate(type:  MyTaskType) {
    destFile = file('build/somefile.txt')
}

artifacts {
    archives file: generate.destFile, name: 'my-artifact', type: 'text', builtBy: generate
}

52.4. アーティファクトの公開 Publishing artifacts

We have said that there is a specific upload task for each configuration. But before you can do an upload, you have to configure the upload task and define where to publish the artifacts to. The repositories you have defined (as described in 「リポジトリ Repositories) are not automatically used for uploading. In fact, some of those repositories only allow downloading artifacts, not uploading. Here is an example of how you can configure the upload task of a configuration:

先ほど、すべてのコンフィギュレーションにアップロード用のタスクが作成されることを説明しました。しかし、実際にアーティファクトをアップロードするには、どこに公開するかを設定する必要があります。プロジェクトに定義したリポジトリ(「リポジトリ Repositories)が、勝手にアップロードに使用されることはありません。実際、それらのリポジトリには、ダウンロードしか許していないものもあるでしょう。次の例は、アップロードタスクの設定方法を示すものです。

例52.5 アップロードタスクの設定

build.gradle

repositories {
    flatDir {
        name "fileRepo"
        dirs "repo"
    }
}

uploadArchives {
    repositories {
        add project.repositories.fileRepo
        ivy {
            credentials {
                username "username"
                password "pw"
            }
            url "http://repo.mycompany.com"
        }
    }
}

As you can see, you can either use a reference to an existing repository or create a new repository. As described in 「Ivyリゾルバについて More about Ivy resolvers, you can use all the Ivy resolvers suitable for the purpose of uploading.

この例のように、定義済みのリポジトリを参照することもできますし、新しくリポジトリ定義を作って追加することもできます。「Ivyリゾルバについて More about Ivy resolversのときと同じように、アップロードでもすべてのIvyリポジトリリゾルバを使うことができます。

If an upload repository is defined with multiple patterns, Gradle must choose a pattern to use for uploading each file. By default, Gradle will upload to the pattern defined by the url parameter, combined with the optional layout parameter. If no url parameter is supplied, then Gradle will use the first defined artifactPattern for uploading, or the first defined ivyPattern for uploading Ivy files, if this is set.

アップロード先のリポジトリ定義に複数のレイアウトパターンが含まれている場合、どのパターンに従ってファイルをアップロードするか決定しなければなりません。 デフォルトでは、Gradleはurlパラメーターを参照します。layoutが定義されていれば、それも併せて使用します。 urlパラメーターが未定義の場合は、定義されているartifactPatternのうち最初のものがアップロードに使用され、また、定義されているivyPatternのうち最初のものがivyファイルのアップロードに使用されます。

Uploading to a Maven repository is described in 「Mavenリポジトリとの相互作用Interacting with Maven repositories.

Mavenリポジトリへのアップロードについては、「Mavenリポジトリとの相互作用Interacting with Maven repositoriesをご参照ください。

52.5. プロジェクトライブラリについての追記事項More about project libraries

If your project is supposed to be used as a library, you need to define what are the artifacts of this library and what are the dependencies of these artifacts. The Java plugin adds a runtime configuration for this purpose, with the implicit assumption that the runtime dependencies are the dependencies of the artifact you want to publish. Of course this is fully customizable. You can add your own custom configuration or let the existing configurations extend from other configurations. You might have a different group of artifacts which have a different set of dependencies. This mechanism is very powerful and flexible.

プロジェクトがライブラリとして使用される場合、そのライブラリのアーティファクトは何か、アーティファクトが依存しているライブラリは何か、定義しておく必要があります。Javaプラグインは、この目的のためにruntimeというコンフィギュレーションを追加します。これは、公開したいアーティファクトはruntime依存関係に依存しているはずだ、という暗黙的な仮定の上での仕様ですが、もちろんこのあたりの設定は完全にカスタマイズ可能です。独自のコンフィギュレーションを作成してもいいし、既存のコンフィギュレーションの継承元を変えてもいいでしょう。別の依存関係をもつ別のアーティファクトを加えることもできます。このメカニズムは非常に強力で、柔軟性豊かなものです。

If someone wants to use your project as a library, she simply needs to declare which configuration of the dependency to depend on. A Gradle dependency offers the configuration property to declare this. If this is not specified, the default configuration is used (see 「依存するコンフィギュレーションの指定 Dependency configurations). Using your project as a library can either happen from within a multi-project build or by retrieving your project from a repository. In the latter case, an ivy.xml descriptor in the repository is supposed to contain all the necessary information. If you work with Maven repositories you don't have the flexibility as described above. For how to publish to a Maven repository, see the section 「Mavenリポジトリとの相互作用Interacting with Maven repositories.

誰かがあなたのプロジェクトをライブラリとして使いたいとしましょう。そのときすべきことは、あなたのプロジェクトの内、どのコンフィグレーションに依存するのか指定することだけです。Gradleの依存関係定義では、configurationというプロパティを指定できるようになっています。もしこのプロパティが指定されていなければ、defaultコンフィギュレーションが使用されます(「依存するコンフィギュレーションの指定 Dependency configurationsをご参照ください)。 あるプロジェクトがライブラリとして使われるのには、二つのケースがあります。マルチプロジェクトの中からライブラリとして参照される場合と、リポジトリからプロジェクトを取得する場合です。後者のケースでは、リポジトリにあるivy.xmlが必要な情報を全て含めることになっていますので、Mavenリポジトリを使う場合は先ほど述べたような柔軟性は持てません。Mavenリポジトリへライブラリを公開する方法については、「Mavenリポジトリとの相互作用Interacting with Maven repositoriesをご覧ください。



[26] To be exact, the Base plugin provides those tasks. This plugin is automatically applied if you use the Java plugin.

[27] 正確に言うと、Baseプラグインがこれらのタスクを提供します。Baseプラグインは、Javaプラグインを使うと自動的に適用されます。