Gradleでは自体はほとんどすべての機能をプラグインとして提供される、基本的なフレームワーク及びコア概念を提供します。
例えば、構築するためにJavaアプリケーションの機能は、Javaプラグインによって実装されます。
Gradleでは、このようなアンドロイドのGradleプラグインとして、コア言語のプラグインの多くを建て、基本的には建築作業のほとんどを満たすことができますが、いくつかのプラグインが組み込まれていないか、一部の機能が提供されていませんが、私たちが使用するプラグインをカスタマイズすることができ、Javaベースのプラグインの拡張機能です。
エフェクトプラグイン
プラグインなどように、コンパイル、テスト、パッケージング、などのタスクのシリーズをパッケージ化することができます。
Javaプラグインを適用した後、例えば、定義することができる挿入規則は、ソースコードのsrc /メイン/ javaディレクトリ内の位置を合意しました。
アプリケーションプログラムアプリケーションのプラグ構成を挿入したとき、ウィジェットパッケージが自動的に設定することができます。
Gradleのウィジェットモデルは、{}のAndroidのGradleアンドロイドの、例えば、DSL構成要素を追加するように拡張することができます
これは、我々はちょうどそれが、方法を提供し、または当社のプロジェクトがビルドするために拡張できるタスクを使用して、合意された方法でそれを実行する必要があり、プラグインです。
同様のコードプラグを使用して、高度にモジュールビルドスクリプトの再利用性を向上させる組織および可読性を高めるためにカプセル化され得ます。
プラグインタイプ
2プラグインのGradleがあります。
- スクリプトは、プラグイン
- バイナリのプラグイン
スクリプトは、プラグイン
スクリプトプラグインは通常、スクリプトです。
スクリプトプラグインの事実、真のプラグインとしてみなすことはできませんが、我々はその役割を無視することはできません、それはモジュラーベースのスクリプトです。
複雑なスクリプトファイルをブロックに分割された私たちは、セグメント仕上げは、1つのスクリプトプラグインの個別の責任に分割することができます。
パッケージスクリプトツールutils.gradleとして、当社の通常のパッケージのようなUtilsのツール
バイナリのプラグイン
バイナリプラグが達成されたプラグインプラグインターフェースは、プログラム構造を操作します。
バイナリプラグインは通常、発売された別の瓶にパッケージされています。
プラグインの見つけ
Gradleでは、専用のウェブサイトを持っていると、プラグインのために公開することが可能になりhttps://plugins.gradle.orgを
もちろん、あなたはGitHubの上で検索することができ、オープンソースは、強力な力です。
プラグインを使用します
それを見つけるために、プラグインに必要を使用して、我々のプロジェクトに適用します。
私たちのプロジェクトへのプラグインアプリケーションは、それを使用することができます。
だから、プラグインを使用すると、2つの手順が必要です。
- プラグインを検索し、クラスパスに追加
- プロジェクトへのアプリケーションのプラグイン
プラグインがあるいったんアプリケーションがそのAPIを使用することができます。
プラグインアプリケーションは、プラグイン・ターゲット・プロジェクトを実行するPlugin.apply（T）メソッド。
アプリケーションプラグは冪等、適用時間及び効果が同一になるとあります。
アプリケーション・スクリプト・プラグイン
スクリプトプラグイン上述したように、実際のスクリプト、スクリプトアプリケーションはプラグイン事実、このスクリプトにロードされます。
ロードされてくるスクリプトから適用されます使用します
apply from: 'other.gradle'スクリプトは、ローカルに存在することができ、それはまた、ネットワーク上に存在することができます。
ローカル相対パスは、アイテムの使用に存在します。
あなたは、HTTPのURLがネットワーク上に存在する使用する必要があります。
アプリケーションバイナリのプラグイン
バイナリのプラグインアプリケーションそのIDアプリケーションで。
プラグインIDプラグインのグローバル一意識別子、または名前です
そんなに特別なGradleのコアプラグインは、「Javaの」Javaプラグインのように、彼らは短いIDを持っているということです。
他のすべてのバイナリプラグは、プラグインID（com.github.foo.bar）の形で完全修飾しなければなりません。
IDプラグインで使用するこれは、プラグイン{}またはbuildscript {} Aの使用に依存します。
Gardleの一部は自動的にアプリケーションでのGradleによって解析され、コア・プラグインは、分散されています。
他のバイナリのプラグインが見つかりましたし、適用する前に解決する必要があります。
Gradleでは、通常、探すためにいくつかの場所を以下の
- 上記のサイトまたはカスタム倉庫のプラグイン
- ジャー指定された外部依存関係
- プロジェクトのディレクトリ内のソースファイルを探していBUILDSRC
- プラグインスクリプトの声明
プラグインを使用する方法は2つあり、一方が他方のbuildscript {}アプリケーションのプラグインを使用することで、新しいプラグイン{}アプリケーションのプラグインを使用することです。
Gradleでは、現在のプラグインを推奨{}。
ここで使用するには、2つの方法があります。
バイナリプラグbuildscriptを使用して、アプリケーション{}
Buildscript {}バイナリ使用してブロックプラグインアプリケーション方式Project.apply（）によって達成されます。
アプリケーションのJavaプラグイン：build.gradle
apply plugin: 'java'「Javaは」ID Javaプラグインここで、org.gradle.api.plugins.JavaPluginに対応するタイプであります
また、アプリケーションのプラグインを入力することができます。build.gradle
apply org.gradle.api.plugins.JavaPluginorg.gradle.api.pluginsはデフォルトでインポートされるので、それは直接直接として書かれたパッケージ名を削除することができます
apply plugin:JavaPlugin使用するサードパーティのプラグインが構成されなければならない}クラスパスのみ{buildscriptを使用することができます。
Gradleでは、この組み込み関数とは異なり、Gradleの分布の責任です。
あなたはそれが最初に設定する必要があります使用したい場合たとえば、私たちのAndroidのGradleが挿入され、それは、Androidのリリースサードパーティ製プラグインに属し
buildscript {
repositories {
mavenCentral()
google()
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:3.2.0'
}
}アンドロイドのGradle jcenterインサートは倉庫でホストされているので、リポジトリ{} jcenter倉庫を追加する必要があります。
buildscript {}はブロックプロジェクトを構築する前に、準備及び構成に依存し、所望の構成に依存するのローカル初期化のためのプロジェクトは、プラグを適用することができるされています。
apply plugin: 'com.android.application'設定はbuildscriptに依存している場合は、{}先にクラスパスにないこのプラグインを見つけるために、プロンプトが表示されます。
プラグインのDSLアプリケーションバイナリプラグインを使用します
プラグインのDSL構成が簡単にアクセスのGradleプラグインのウェブサイトにプラグインすることができます。
この構成では、構成ブロックであるPluginDependenciesSpec例
コア・アプリケーション・プラグイン
plugins {
id 'java'
}サードパーティ製のプラグインを使用します（フォームが完全修飾でなければなりません）ウィジェットIDを使用します
plugins {
id 'com.jfrog.bintray' version '0.4.1'
}{}アプリケーションのプラグインは依存構成を適用する必要があり、その後、メソッドを使用し、唯一のあなたはプラグイン{}でそれを設定する必要はありませんプラグインを使用してください。
プラグインDSL制限
プラグインのDSLプラグインが合理化の手順を使用しますが、いくつかの制限がありますが、その構文は固定されており、変更することはできません
plugins {
id «plugin id» // (1)
id «plugin id» version «plugin version» [apply «false»] // (2)
}- コアプラグインに適したサードパーティ製のプラグインを持っていた名前をロードまたは省略されています
- 解決する必要があるサードパーティ製プラグインのために
プラグインIDとプラグインのバージョンが必要とされ、定数、リテラル文字列でなければなりません。他のステートメントが許可されていません
適用はオプションで、デフォルトはtrueです。とき、プラグインアプリケーションのプラグインのデフォルトの動作かどうかを制御するためにすぐに使用されます。
プラグインは、{}ブロック内の他のブロック構成内にネストされていない、スクリプトは、トップレベルのモジュールである必要があります。
のみプロジェクトのビルドスクリプトで使用することができるプラグイン{}内の現在のバージョン5.6.2では、スクリプトは、settings.gradleとinit.gradleスクリプトをプラグインすることができません。
サブプロジェクトにアプリケーション・プラグイン
プラグインは、{}いくつかの項目ではなく、プロジェクトのすべてに適用されますプラグインアプリケーションのオプションを使用することができます。
デフォルトの挿入プラグインは、{}直ちに解析し、適用すること。
あなたは偽の適用を使用することができGradleのは、現在のプロジェクトには適用されません告げる
サブスクリプトでプラグインを適用し、次に<
settings.gradle
include 'helloA'
include 'helloB'
include 'goodbyeC'build.gradle
plugins {
id 'org.gradle.sample.hello' version '1.0.0' apply false
id 'org.gradle.sample.goodbye' version '1.0.0' apply false
}
subprojects {
if (name.startsWith('hello')) {
apply plugin: 'org.gradle.sample.hello'
}
}goodbyeC / build.gradle
plugins {
id 'org.gradle.sample.goodbye'
}上記の例は、それぞれ、複数のサブプロジェクトに異なるプラグインを使用する方法を示します。
プラグインディレクトリBUILDSRCの使用
BUILDSRCは、プラグイン・プロジェクトのディレクトリにも使用することができるが、プラグインIDを定義しなければなりません。
ここでBUILDSRCを使用してウィジェットカタログの一例です
このプラグインは、私の-プラグインがmy.MyPlugin達成されるプラグインクラスのIDです
BUILDSRCを/ build.gradle
plugins {
id 'java'
id 'java-gradle-plugin'
}
gradlePlugin {
plugins {
myPlugins {
id = 'my-plugin'
implementationClass = 'my.MyPlugin'
}
}
}
dependencies {
compileOnly gradleApi()
}プラグインを使用します
plugins {
id 'my-plugin'
}プラグインの管理
このpluginManagement DSLは、プラグインを管理するために使用され、それは、プラグイン、カスタム倉庫、カスタム解析規則を設定することができます。
pluginManagementは、{}は2つの場所で定義されます。
- settings.gradle年には、それが最初のモジュールでなければなりません
- init.gradle里
settings.gradle
pluginManagement {
plugins {
}
resolutionStrategy {
}
repositories {
}
}init.gradle
settingsEvaluated { settings ->
settings.pluginManagement {
plugins {
}
resolutionStrategy {
}
repositories {
}
}
}カスタム倉庫
デフォルトのプラグインはプラグインのGradleプラグインのウェブサイトを探しています
我々は、独自の倉庫に構成} {リポジトリに{} pluginManagementでき
Gradleのは、順番に倉庫の順序に従って、プラグインの設定を探します
settings.gradle
pluginManagement {
repositories {
maven {
url '../maven-repo'
}
gradlePluginPortal()
ivy {
url '../ivy-repo'
}
}
}まず、見つける../maven-repo位置のMavenリポジトリは、再びのGradleプラグインのサイトを見つけることができず、最終的にはツタ倉庫の../ivy-repoあります。
プラグインのバージョン管理
プラグイン{}構文内に配置されたプラグでpluginManagement {}内に固定された制限されません。
すべてのバージョンはgradle.propertiesを使用して別のスクリプトまたは構成プロパティファイルに配置することができます
settings.gradle
pluginManagement {
plugins {
id 'org.gradle.sample.hello' version "${helloPluginVersion}"
}
}build.gradle
plugins {
id 'org.gradle.sample.hello'
}gradle.properties
helloPluginVersion=1.0.0構文解析規則
解析ルールプラグルールを解析し、カスタムルールは、ウィジェットプラグイン{}ブロックプラグインのような要求されたバージョンまたは明示的に指定された実装ワーク座標を変更するよう要求し、変更することができます。
レーンresolutionStrategy {}構成でpluginManagement {}内のルールを解析します。
プラグインの解決ポリシー：
pluginManagement {
resolutionStrategy {
eachPlugin {
if (requested.id.namespace == 'org.gradle.sample') {
useModule('org.gradle.sample:sample-plugins:1.0.0')
}
}
}
repositories {
maven {
url '../maven-repo'
}
gradlePluginPortal()
ivy {
url '../ivy-repo'
}
}
}これは、指定されたプラグインの実装のGradleワーク、代わりに組み込みプラグインIDのMaven / lvyデフォルトマッピング座標からの使用を伝えます。
ウィジェット外被加工物の実際の実装に加えて、ウィジェットlvyカスタム・リポジトリとMavenプラグタグは、ワークを含んでいなければなりません。
Gradleのプラグイン開発を表示することができ、倉庫へのプラグインのカスタム出版について：
ポータル
プラグインマーカーアーティファクト（ウィジェットワークマーク）
アーティファクト（ワーク）：ここでのコンセプトは、Mavenの中に挿入されます
アーティファクト抽象的な概念は、それはMavenプロジェクトファイルが生成されますです。
Mavenプロジェクトは、複数のアーティファクトを生成することがあり、それはjarファイル、ソースファイル、バイナリファイル、warファイル、あるいはPOMファイルであってもよいです。
各アーティファクトは、グループIDは、（通常、逆ドメイン名は、パッケージの名前のような）、案件ID（名前）とバージョン番号た
3つのアーティファクトの組合せを表す座標：のgroupId：artifiactIdました：バージョン
唯一のグローバルにユニークなIDバージョンプラグインとプロパティ宣言によってプラグインDSLブロック、Gradleのプラグを達成するために、工作物の座標を見つける方法のために、従って必要があるため。
この目的のために、Gradleのは、ワークマークplugin.id:plugin.id.gradle.plugin:plugin.versionの座標を使用してウィジェットを見つけます。
このタグは、プラグインの実装の実際のニーズに依存しています。Javaの-Gradleでは、プラグインは自動的にこれらのタグを発行します。
たとえば、次のサンプル・プラグインの完全な例では、JavaベースのGradle-プラグインを使用する方法を示し、プラグインやツタに公開プラグインの組み合わせをのmaven-公開しorg.gradle.sample.goodbyeするプラグインorg.gradle.sample.helloリリースされますアイビーとMavenリポジトリ。
完全なプラグインリリースの例
plugins {
id 'java-gradle-plugin'
id 'maven-publish'
id 'ivy-publish'
}
group 'org.gradle.sample'
version '1.0.0'
gradlePlugin {
plugins {
hello {
id = 'org.gradle.sample.hello'
implementationClass = 'org.gradle.sample.hello.HelloPlugin'
}
goodbye {
id = 'org.gradle.sample.goodbye'
implementationClass = 'org.gradle.sample.goodbye.GoodbyePlugin'
}
}
}
publishing {
repositories {
maven {
url '../../consuming/maven-repo'
}
ivy {
url '../../consuming/ivy-repo'
}
}
}Gradleでは、以下の構造を持つことになります操作を公開します
以下のような前述のプラグ及びプラグIDのワークマークとの間のマッピング関係を調整します。
以下の実施例においてこんにちはウィジェット
- IDの是のorg.gradle.sample.hello
- バージョン1.0.0
org.gradle.sample.gradle.plugin：1.0.0アーティファクト座標位置のMavenリポジトリはorg.gradle.sample.helloです
- groupId：org.gradle.sample
- たartifactId：org.gradle.sample.gradle.plugin
- バージョン：1.0.0
対応は言及plugin.idの上にある：plugin.id.gradle.plugin：plugin.version
私が悪い以下の詳細な記述する場合は、「AndroidのGradleのDefinitive Guideの」とのGradleのユーザーマニュアルを表示することができます。