Gradle plugin

Gradle itself only provides the basic framework and core concepts, almost all the functions are provided by way of plug-ins.

For example, to build a Java application functionality is implemented by the Java plug.

Gradle built a lot of the core language plug-ins, can basically meet most of the building work, but some plug-ins have not built or some functions do not provide, we can customize the plugin to use, such as Android Gradle plugin is Java-based plug-in extensions.

Effect plug-ins

Plug-in can package a series of tasks, such as compiling, testing, packaging and so on.

Inserted convention may define, for example after applying the Java plug agreed position in the source code src / main / java directory.

Widget package can be configured automatically when the application program application plug inserted configuration.

Gradle widget model can be extended to add DSL configurable element, for example of the Android Gradle android {}

This is the plug-in, we just need to follow it in the agreed manner, using the task it provides, methods, or can extend our project to build.

Using similar code plug may be encapsulated in order to improve reusability of the highly modular build script, organization and enhance readability.

Plug-in type

There are two plug-in Gradle

• Script plug-in
• Binary plug-in

Script plug-in

Script plug-in is usually a script.

Script plug-in fact, can not be regarded as a true plug-in, but we can not ignore its role, it is the script of a modular basis.

We can complex script file is divided into blocks, the segment finishing, split into one script plugins distinct responsibilities.

Utils tools like our usual package as a package script tool utils.gradle

Binary plug-in

Binary plug is achieved Plugin plug interface programmatically manipulate the construct.

Binary plug-in is usually packaged in a separate jar was released.

Plugin found

Gradle has a dedicated website and look for plug-ins can be published https://plugins.gradle.org

Of course, you can search on Github, open source is a powerful force.

Use plug-ins

To use a plug-in Required to find it, and then apply it to our project.

The plug-in application to our project can use it.

So using a plug-in requires two steps:

1. Find the plug-in and added to the classpath
2. Application plug-ins to the project

Once the plug-in is the application can use its API up.

Plug-in application is executed plug-target projects Plugin.apply (T) method.

Application plug is idempotent, application times and once the effect is the same.

Application scripting plug-in

As mentioned above script plug-in is actually a script, the script application plug-in fact, this script is loaded in.

Use apply from the script come loaded

apply from: 'other.gradle'

Scripts can exist locally, it may also be present on the network.

Local relative paths exist on the use of the item.

You must use the HTTP URL exists on the network.

Application Binary plug-in

Binary plug-in application by their ID applications.

Plug-in ID is a globally unique identifier, or name of the plug-in

Gradle core plug so special is that they have a short ID, such as a "java" Java plug-in.

All other binary plug must be fully qualified in the form of plug-in ID (com.github.foo.bar).

ID plug-in which you use depends on the use of plugins {} or buildscript {} a.

The core plug-in is distributed as part of Gardle is automatically parsed by Gradle in the application.

The other binary plug-ins must be found and resolved before applying.

Gradle usually following several places to look for

• Plugins on the site mentioned above or custom warehouse
• Jar specified external dependencies
• Looking for the source file in the directory of the project buildSrc
• Statement of plug-in scripts

There are two ways to use plug-in, one is to use new plugins {} application plug-in, the other is to use buildscript {} application plug-ins.

Gradle currently recommended plugins {}.

Here are two ways to use.

Application using binary plug buildscript {}

Buildscript {} block using a binary plug-in application is achieved by a method Project.apply () a.

Application Java plug-in: build.gradle

apply plugin: 'java'

"Java" is the ID Java plug-in here, the type of which corresponds to the org.gradle.api.plugins.JavaPlugin

You can also type application plug-ins: build.gradle

apply org.gradle.api.plugins.JavaPlugin

Because org.gradle.api.plugins is imported by default, so it can directly remove the package name directly written as

apply plugin:JavaPlugin

Third-party plug-ins to be used must be configured} class path can only be used buildscript {.

Unlike Gradle this built-ins, is the responsibility of the Gradle distribution.

For example, our Android Gradle inserted, it belongs to the third-party plug-ins released Android, if you want to use it must first be configured

buildscript {
    repositories {
        mavenCentral()
        google()
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:3.2.0'
    }
}

Because Android Gradle jcenter insert is hosted on a warehouse, it is necessary to add the repositories {} jcenter warehouse.

buildscript {} is a block before building project, the project for the preparation and the local initialization of configuration-dependent, dependent on the desired configured, the plug can be applied:

apply plugin: 'com.android.application'

If the configuration is dependent on buildscript {} is not in the class path ahead will be prompted to find this plugin.

Use plugins DSL application binary plug

plugins DSL configuration can easily plug on access Gradle Plugin website.

This configuration is a configuration block PluginDependenciesSpec example

The core application plug-ins

plugins {
    id 'java'
}

Use widget ID (form must be fully qualified) use third-party plug

plugins {
    id 'com.jfrog.bintray' version '0.4.1'
}

Use plugins {} application plug-ins do not have to apply the configuration dependent and then use the method, only you need to configure it in the plugins {}.

plugins DSL restriction

While plugins DSL plug-in will use the steps streamlined, but there are some limitations, its syntax is fixed, and can not be changed

plugins {
    id «plugin id»                                            // (1)
    id «plugin id» version «plugin version» [apply «false»]   // (2)
}

1. Suitable for core plugins have been loaded or abbreviated name had third-party plug
2. For third-party plug-ins that need to be resolved

plugin id and plugin version is required and must be a constant, literal string. Other statements are not allowed

apply is optional, the default is true; it is used immediately to control whether the default behavior when the plug-in application plug-ins.

The plugins {} is not nested within another block configuration in the block, the script must be top-level module.

In the current version 5.6.2 in plugins {} can only be used in the project build script, the script can not plug in, settings.gradle and init.gradle script.

Application plug-ins to subprojects

Plugins {} can use the plug-in application option will apply to some items but not all of the project.

The default insert plugins {} immediately be parsed and applied.

You can use apply false tells Gradle does not apply to the current project,
then apply plugin in sub script < > Widget application or plugins {}

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'
}

The above example demonstrates how to use multiple subprojects different plug-ins, respectively.

The use of plug-in directory buildSrc

BuildSrc plug-in directory of the project may also be used, but must be defined plug-in ID.

Here is an example of the widget catalog using buildSrc

This plugin is a plugin class ID my-plugin is achieved my.MyPlugin
buildSrc / the build.gradle

plugins {
    id 'java'
    id 'java-gradle-plugin'
}

gradlePlugin {
    plugins {
        myPlugins {
            id = 'my-plugin'
            implementationClass = 'my.MyPlugin'
        }
    }
}

dependencies {
    compileOnly gradleApi()
}

Use plug-ins

plugins {
    id 'my-plugin'
}

Plugin Management

This pluginManagement DSL is used to manage plug-ins, it can be configured plug-ins, custom warehouses, custom parsing rules.

pluginManagement {} is defined only in two places:

• settings.gradle years, and it must be the first module
• init.gradle 里

settings.gradle

pluginManagement {
    plugins {
    }
    resolutionStrategy {
    }
    repositories {
    }
}

init.gradle

settingsEvaluated { settings ->
    settings.pluginManagement {
        plugins {
        }
        resolutionStrategy {
        }
        repositories {
        }
    }
}

Custom warehouse

The default plugins are looking for plug-in Gradle plugin website

We can pluginManagement {} in the repositories {} configuration in its own warehouse

Gradle will in turn look for plug-in configuration in accordance with the order of the warehouse

settings.gradle

pluginManagement {
    repositories {
        maven {
            url '../maven-repo'
        }
        gradlePluginPortal()
        ivy {
            url '../ivy-repo'
        }
    }
}

First, the Maven repository located ../maven-repo find, can not find again Gradle plugin site, and finally located ../ivy-repo of ivy warehouse.

Plug-in version management

In pluginManagement {} in the plug arranged in plugins {} syntax is no fixed limit.

All versions can be placed in a separate script or configuration property files using 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

Parsing rules

Parsing rules plug is parsing rules, custom rules can change the widget plugins {} block plug-in requests, such as changing the requested version or explicitly specified implementation workpiece coordinate.

Parsing rules in pluginManagement {} in Lane resolutionStrategy {} configuration.

Plug-resolution policy:

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'
        }
    }
}

This tells the specified plug-in implementation Gradle workpiece, instead of using the built-in from the plug-in ID Maven / lvy default mapping coordinates.

In addition to the actual implementation of the workpiece outside the widget, widget lvy custom repository and Maven plug tag must contain a workpiece.

About the plug-in custom publishing to the warehouse can view the Gradle Plugin Development:
Portal

Plugin Marker Artifacts (widget workpiece mark)

The concept here is inserted into a Maven: Artifact (workpiece)

Artifact abstract concept, it is a Maven project file will be generated.
A Maven project may generate multiple Artifact, it may be jar files, source files, binary files, war files, or even pom file.
Each artifact has a group ID (usually the reverse domain name, like the name of the package), a artifact ID (a name) and a version number,
which represents a combination of three artifact coordinates: groupId: artifiactId: version

Since plugins DSL block only by a globally unique id version plug-ins and property declarations, Gradle therefore a need for a method to find the coordinates of a workpiece to achieve plug.
For this purpose, Gradle will find the widget using the coordinate of the workpiece mark plugin.id:plugin.id.gradle.plugin:plugin.version.
This tag is dependent on the actual needs of the plug-in implementation. java-gradle-plugin will automatically publish these tags.

For example, the following sample-plugins complete example demonstrates how to use java-gradle-plugin, maven-publish a combination of plug-ins and ivy-publish plug-ins and will be released org.gradle.sample.hello plug-in to org.gradle.sample.goodbye Ivy and Maven repository.

Complete plug-release example

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 publish operation will have the following structure

Like coordinate mapping relationship between the plug and plug id workpiece marks previously mentioned.

In the following Examples hello widget

• id 是 org.gradle.sample.hello
• Version 1.0.0

Located Maven repository artifact coordinates is org.gradle.sample.hello: org.gradle.sample.gradle.plugin: 1.0.0

• groupId: org.gradle.sample
• artifactId: org.gradle.sample.gradle.plugin
• version: 1.0.0

Correspondence is above mentioned plugin.id: plugin.id.gradle.plugin: plugin.version

---

If I describe bad or less detailed, you can view the "Android Gradle Definitive Guide" and Gradle user manual.