第53章 Mavenプラグイン

This chapter is a work in progress

この章は執筆途中です。

The Maven plugin adds support for deploying artifacts to Maven repositories.

Mavenプラグインは、Mavenリポジトリへのアーティファクトのデプロイに対するサポートを追加します。

53.1. 使用方法Usage

To use the Maven plugin, include the following in your build script:

Mavenプラグインを使うには、ビルドスクリプトに以下を含めます:

例53.1 Mavenプラグインの利用

build.gradle

apply plugin: 'maven'

53.2. タスクTasks

The Maven plugin defines the following tasks:

Mavenプラグインは以下のタスクを定義しています:

表53.1 Mavenプラグイン - タスクMaven plugin - tasks

タスク名Task name 依存先Depends on Type 説明Description
install 関連するアーカイブをビルドするすべてのタスク All tasks that build the associated archives. Upload Mavenメタデータの生成を含め、関連するアーティファクトをローカルMavenキャッシュにインストールする。 デフォルトではinstallタスクはarchivesコンフィグレーションに関連付けられる。 このコンフィグレーションのデフォルトでは要素としてJARのみを持つ。 ローカルリポジトリへのインストールに関して詳しく学ぶためには「ローカルリポジトリへのインストールInstalling to the local repositoryを参照のこと。 Installs the associated artifacts to the local Maven cache, including Maven metadata generation. By default the install task is associated with the archives configuration. This configuration has by default only the default jar as an element. To learn more about installing to the local repository, see: 「ローカルリポジトリへのインストールInstalling to the local repository

53.3. 依存関係管理Dependency management

The Maven plugin does not define any dependency configurations.

Mavenプラグインはいかなる依存関係のコンフィグレーションも定義していません。

53.4. 規約プロパティConvention properties

The Maven plugin defines the following convention properties:

Mavenプラグインは以下の規約プロパティを定義しています:

表53.2 Mavenプラグイン - プロパティMaven plugin - properties

プロパティ名 Property name Type デフォルト値Default value 説明Description
pomDirName String poms 生成されたPOMを書き出すディレクトリのパス名をビルドディレクトリからの相対パスで指定 The path of the directory to write the generated POMs, relative to the build directory.
pomDir File (read-only) buildDir/pomDirName 生成されたPOMを書き出すディレクトリ The directory where the generated POMs are written to.
conf2ScopeMappings Conf2ScopeMappingContainer n/a GradleコンフィグレーションからMavenスコープへのマッピング指示。「依存関係のマッピングDependency mapping参照。 Instructions for mapping Gradle configurations to Maven scopes. See 「依存関係のマッピングDependency mapping.

These properties are provided by a MavenPluginConvention convention object.

これらのプロパティは規約オブジェクトMavenPluginConventionが提供します。

53.5. 規約メソッドConvention methods

The maven plugin provides a factory method for creating a POM. This is useful if you need a POM without the context of uploading to a Maven repo.

MavenプラグインはPOM生成のためのファクトリメソッドを提供します。 これはMavenリポジトリへのアップロードを必要としないPOMが必要なときに便利です。

例53.2 スタンドアロンPOMの生成

build.gradle

task writeNewPom << {
    pom {
        project {
            inceptionYear '2008'
            licenses {
                license {
                    name 'The Apache Software License, Version 2.0'
                    url 'http://www.apache.org/licenses/LICENSE-2.0.txt'
                    distribution 'repo'
                }
            }
        }
    }.writeTo("$buildDir/newpom.xml")
}

Amongst other things, Gradle supports the same builder syntax as polyglot Maven. To learn more about the Gradle Maven POM object, see MavenPom. See also: MavenPluginConvention

そのほか、Gradleは多言語Mavenと同じビルダー文法をサポートします。 Gradle Maven POMオブジェクトについてもっと学ぶためには、 MavenPomを参照してください。また、MavenPluginConventionも有用です。

53.6. Mavenリポジトリとの相互作用Interacting with Maven repositories

53.6.1. はじめにIntroduction

With Gradle you can deploy to remote Maven repositories or install to your local Maven repository. This includes all Maven metadata manipulation and works also for Maven snapshots. In fact, Gradle's deployment is 100 percent Maven compatible as we use the native Maven Ant tasks under the hood.

Gradleでは、リモートMavenリポジトリにデプロイすることも、ローカルMavenリポジトリにインストールすることもできます。 これにはすべてのMavenメタデータの操作が含まれ、Mavenスナップショットに対しても適用できます。 実際、Gradleのデプロイは、ネィティブのMaven Antタスクを内部で利用するのと同じく、100%Maven互換です。

Deploying to a Maven repository is only half the fun if you don't have a POM. Fortunately Gradle can generate this POM for you using the dependency information it has.

もしPOMがないとしたら、Mavenリポジトリへのデプロイは楽しさ半減です。 幸運なことに、GradleはPOM自身の持つ依存関係の情報を用いて、このPOMを生成してくれます

53.6.2. MavenリポジトリへのデプロイDeploying to a Maven repository

Let's assume your project produces just the default jar file. Now you want to deploy this jar file to a remote Maven repository.

プロジェクトが単にデフォルトのJARファイルを生成するだけだとしましょう。 このJARファイルをリモートMavenリポジトリにデプロイしたいとします。

例53.3 リモートMavenリポジトリへのファイルアップロード

build.gradle

apply plugin: 'maven'

uploadArchives {
    repositories {
        mavenDeployer {
            repository(url: "file://localhost/tmp/myRepo/")
        }
    }
}

That is all. Calling the uploadArchives task will generate the POM and deploys the artifact and the POM to the specified repository.

これが全てです。 uploadArchivesタスクを呼び出すことでPOMが生成され、 アーティファクトとPOMが指定されたリポジトリにデプロイされます。

There is more work to do if you need support for other protocols other than file. In this case the native Maven code we delegate to needs additional libraries. Which libraries are needed depends on what protocol you plan to use. The available protocols and the corresponding libraries are listed in 表53.3「Mavenデプロイに対するプロトコルJARProtocol jars for Maven deployment (those libraries have transitive dependencies which have transitive dependencies). [28] For example, to use the ssh protocol you can do:

file以外のプロトコルをサポートする必要があるなら、他にも少しやるべきことがあります。 この場合、処理を委譲するネィティブMavenコードが追加のライブラリを必要とします。 どのライブラリが必要になるかは、必要なプロトコルによります。 利用可能なプロトコルと対応するライブラリは表53.3「Mavenデプロイに対するプロトコルJARProtocol jars for Maven deploymentにリストアップされています (推移的な依存関係を持つこれらのライブラリは、さらに推移的な依存関係を持ちます)。 [29] 例えば、SSHプロトコルを使うには次のようにできます:

例53.4 SSH経由でのファイルアップロード

build.gradle

configurations {
    deployerJars
}

repositories {
    mavenCentral()
}

dependencies {
    deployerJars "org.apache.maven.wagon:wagon-ssh:2.2"
}

uploadArchives {
    repositories.mavenDeployer {
        configuration = configurations.deployerJars
        repository(url: "scp://repos.mycompany.com/releases") {
            authentication(userName: "me", password: "myPassword")
        }
    }
}

There are many configuration options for the Maven deployer. The configuration is done via a Groovy builder. All the elements of this tree are Java beans. To configure the simple attributes you pass a map to the bean elements. To add bean elements to its parent, you use a closure. In the example above repository and authentication are such bean elements. 表53.4「MavenDeployerのコンフィグレーション要素Configuration elements of the MavenDeployer lists the available bean elements and a link to the Javadoc of the corresponding class. In the Javadoc you can see the possible attributes you can set for a particular element.

Mavenデプロイヤーには多くのコンフィグレーションオプションがあります。 コンフィグレーションはGroovyビルダーで行うことができます。 このツリーのすべての要素はJava beansです。 単純な属性を設定するためには、beanの要素にmapを渡してやります。 親要素に別のbean要素を追加するには、クロージャを使います。 上記の例では、repositoryauthenticationがbean要素です。 利用可能なbean要素と対応するクラスのJavaDocへのリンクは、表53.4「MavenDeployerのコンフィグレーション要素Configuration elements of the MavenDeployerにリストアップされています。 JavaDocでは特定の要素にセットできる属性を確認できます。

In Maven you can define repositories and optionally snapshot repositories. If no snapshot repository is defined, releases and snapshots are both deployed to the repository element. Otherwise snapshots are deployed to the snapshotRepository element.

Mavenではリポジトリに加えて、オプションでスナップショットリポジトリを定義できます。 スナップショットリポジトリが定義されていない場合、 リリースとスナップショットの両方がrepository要素で指定された先にデプロイされます。 そうでない場合は、スナップショットはsnapshotRepository要素で指定された先にデプロイされます。

表53.3 Mavenデプロイに対するプロトコルJARProtocol jars for Maven deployment

プロトコルProtocol ライブラリLibrary
http org.apache.maven.wagon:wagon-http:2.2
ssh org.apache.maven.wagon:wagon-ssh:2.2
ssh-external org.apache.maven.wagon:wagon-ssh-external:2.2
ftp org.apache.maven.wagon:wagon-ftp:2.2
webdav org.apache.maven.wagon:wagon-webdav:1.0-beta-2
file -

表53.4 MavenDeployerのコンフィグレーション要素Configuration elements of the MavenDeployer

53.6.3. ローカルリポジトリへのインストールInstalling to the local repository

The Maven plugin adds an install task to your project. This task depends on all the archives task of the archives configuration. It installs those archives to your local Maven repository. If the default location for the local repository is redefined in a Maven settings.xml, this is considered by this task.

Mavenプラグインはプロジェクトにinstallタスクを追加します。 このタスクはarchivesコンフィグレーションのすべてのarchivesタスクに依存します。 これらのアーカイブはローカルMavenリポジトリにインストールされます。 もし、ローカルリポジトリの場所がMavenのsettings.xmlで再定義されていたら、このタスクはそれを反映します。

53.6.4. MavenのPOM生成 Maven POM generation

When deploying an artifact to a Maven repository, Gradle automatically generates a POM for it. The groupId, artifactId, version and packaging elements used for the POM default to the values shown in the table below. The dependency elements are created from the project's dependency declarations.

Mavenリポジトリにアーティファクトをデプロイする際、Gradleは自動的にデプロイ用のPOMを生成します。 POMにデフォルトで設定されるgroupIdartifactIdversionpackaging要素の値は以下の表を参照してください。 dependency要素は、プロジェクトで宣言されている依存関係設定から作成されます。

表53.5 Maven POM生成のためのデフォルト値 Default Values for Maven POM generation

Maven Element Maven要素 Default Value デフォルト値
groupId project.group
artifactId uploadTask.repositories.mavenDeployer.pom.artifactId (if set) or archiveTask.baseName.
version project.version
packaging archiveTask.extension

Here, uploadTask and archiveTask refer to the tasks used for uploading and generating the archive, respectively (for example uploadArchives and jar). archiveTask.baseName defaults to project.archivesBaseName which in turn defaults to project.name.

ここで、uploadTaskarchiveTaskは、それぞれ、実際にアーカイブをアップロードするタスクと生成するタスクのことを指しています(例えば、uploadArchivesjar)。 archiveTask.baseNameのデフォルト値はproject.archivesBaseNameで、そのデフォルト値はproject.nameです。

When you set the “archiveTask.baseName” property to a value other than the default, you'll also have to set uploadTask.repositories.mavenDeployer.pom.artifactId to the same value. Otherwise, the project at hand may be referenced with the wrong artifact ID from generated POMs for other projects in the same build.

archiveTask.baseNameをデフォルト以外の値に設定したときは、uploadTask.repositories.mavenDeployer.pom.artifactIdを同じ値に設定することを忘れないでください。 さもないと、近いうちに、同じビルド内の他プロジェクトで生成されたPOMから、プロジェクトが誤ったartifact IDで参照されてしまうかもしれません。

Generated POMs can be found in <buildDir>/poms. They can be further customized via the MavenPom API. For example, you might want the artifact deployed to the Maven repository to have a different version or name than the artifact generated by Gradle. To customize these you can do:

生成されたPOMは、<buildDir>/pomsに出力されます。そのPOMは、さらにMavenPom APIでカスタマイズすることができます。 例えば、Mavenにデプロイするアーティファクトには、Gradleで生成するアーティファクトとは別のバージョンと名前を持たせたくなるかもしれません。このようなカスタマイズを行うには、以下のようにします。

例53.5 pomのカスタマイズ

build.gradle

uploadArchives {
    repositories {
        mavenDeployer {
            repository(url: "file://localhost/tmp/myRepo/")
            pom.version = '1.0Maven'
            pom.artifactId = 'myMavenName'
        }
    }
}

To add additional content to the POM, the pom.project builder can be used. With this builder, any element listed in the Maven POM reference can be added.

POMに追加的な内容を加えるには、pom.projectビルダーを使います。 このビルダーを使えば、Maven POMリファレンスに載っている全ての要素を追加することができます。

例53.6 ビルダースタイルでpomをカスタマイズする

build.gradle

uploadArchives {
    repositories {
        mavenDeployer {
            repository(url: "file://localhost/tmp/myRepo/")
            pom.project {
                licenses {
                    license {
                        name 'The Apache Software License, Version 2.0'
                        url 'http://www.apache.org/licenses/LICENSE-2.0.txt'
                        distribution 'repo'
                    }
                }
            }
        }
    }
}

Note: groupId, artifactId, version, and packaging should always be set directly on the pom object.

注意: groupIdartifactIdversionおよびpackagingは、常にpomオブジェクトに直接設定するべきです。

例53.7 自動生成された内容を変更する

build.gradle

def installer = install.repositories.mavenInstaller
def deployer = uploadArchives.repositories.mavenDeployer

[installer, deployer]*.pom*.whenConfigured {pom ->
    pom.dependencies.find {dep -> dep.groupId == 'group3' && dep.artifactId == 'runtime' }.optional = true
}

If you have more than one artifact to publish, things work a little bit differently. See 「複数アーティファクトを含むプロジェクトMultiple artifacts per project.

2つ以上のアーティファクトを公開したい場合は、すこし難しくなります。「複数アーティファクトを含むプロジェクトMultiple artifacts per projectを参照してください。

To customize the settings for the Maven installer (see「ローカルリポジトリへのインストールInstalling to the local repository), you can do:

Mavenインストーラー(「ローカルリポジトリへのインストールInstalling to the local repository参照)の設定をカスタマイズするには、次のようにします。

例53.8 Mavenインストーラーのカスタマイズ

build.gradle

install {
    repositories.mavenInstaller {
        pom.version = '1.0Maven'
        pom.artifactId = 'myName'
    }
}

53.6.4.1. 複数アーティファクトを含むプロジェクトMultiple artifacts per project

Maven can only deal with one artifact per project. This is reflected in the structure of the Maven POM. We think there are many situations where it makes sense to have more than one artifact per project. In such a case you need to generate multiple POMs. In such a case you have to explicitly declare each artifact you want to publish to a Maven repository. The MavenDeployer and the MavenInstaller both provide an API for this:

Mavenはプロジェクトあたり1つのアーティファクトしか扱うことができません。 これはMavenのPOMの構造を反映しています。 我々は、プロジェクトが2つ以上のアーティファクトを含むことが合理的であるシチュエーションも多いと考えています。 この場合、複数のPOMを生成する必要があります。 このような状況では、Mavenリポジトリに発行するそれぞれのアーティファクトを明示的に宣言する必要があります。 MavenDeployerおよびMavenInstallerが、これに対するAPIを提供します:

例53.9 複数POMの生成

build.gradle

uploadArchives {
    repositories {
        mavenDeployer {
            repository(url: "file://localhost/tmp/myRepo/")
            addFilter('api') {artifact, file ->
                artifact.name == 'api'
            }
            addFilter('service') {artifact, file ->
                artifact.name == 'service'
            }
            pom('api').version = 'mySpecialMavenVersion'
        }
    }
}

You need to declare a filter for each artifact you want to publish. This filter defines a boolean expression for which Gradle artifact it accepts. Each filter has a POM associated with it which you can configure. To learn more about this have a look at PomFilterContainer and its associated classes.

発行するそれぞれのアーティファクトに対してfilterを宣言する必要があります。 filterではGradleアーティファクトが受け付ける論理式を定義します。 それぞれのfilterは関連付けられたPOMを持ち、コンフィグレーション可能です。 より詳しく学ぶためには、PomFilterContainerおよび関連クラスを参照してください。

53.6.4.2. 依存関係のマッピングDependency mapping

The Maven plugin configures the default mapping between the Gradle configurations added by the Java and War plugin and the Maven scopes. Most of the time you don't need to touch this and you can safely skip this section. The mapping works like the following. You can map a configuration to one and only one scope. Different configurations can be mapped to one or different scopes. You can also assign a priority to a particular configuration-to-scope mapping. Have a look at Conf2ScopeMappingContainer to learn more. To access the mapping configuration you can say:

Mavenプラグインは、JavaプラグインとWarプラグインによって追加されたGradleコンフィグレーションと Mavenスコープとの間のデフォルトのマッピングを構成します。 ほとんどの場合これに触れる必要はなく、この節は読み飛ばしていただいてかまいません。 マッピングは次のように動作します。 コンフィグレーションはただ一つのスコープにのみマップできます。 異なるコンフィグレーションは一つ、もしくは異なるスコープにマップできます。 特定のコンフィグレーション-スコープマッピングに優先度を割り当てることもできます。 詳しくはConf2ScopeMappingContainerを参照してください。 マッピングコンフィグレーションにアクセスするには次のようにします:

例53.10 マッピングコンフィグレーションへのアクセス

build.gradle

task mappings << {
    println conf2ScopeMappings.mappings
}

Gradle exclude rules are converted to Maven excludes if possible. Such a conversion is possible if in the Gradle exclude rule the group as well as the module name is specified (as Maven needs both in contrast to Ivy). Per-configuration excludes are also included in the Maven POM, if they are convertible.

Gradleのexcludeルールは、可能であればMavenのexcludeに変換されます。 この変換は、Gradleのexcludeルールにおいてgroupとモジュール名の両方が指定されている場合に可能となります (Ivyとは対照的に、Mavenは両方を必要とするため)。 コンフィグレーション毎のexcludeも、変換可能であればMavenのPOMに含まれます。



[28] It is planned for a future release to provide out-of-the-box support for this

[29] これらは将来のリリースで標準サポートされる予定です