GradlePlugin

gradle plugin的两种方式

  1. 脚本插件模式：apply from: ‘xx.gradle’
  2. 标准插件模式：apply plugin: ‘xxx’

脚本插件模式转换为标准插件模式

直接在apply(Project project)回调时将之前的脚本插件代码copy过来即可，这里的上下文会缺少project，因此需要用project.with{}包裹原本的脚本代码

gradle plugin执行流程

两种gradle plugin的都是相当于动态替换插件代码在apply的地地方，也就apply plugin时直接调用到apply(Project project)

针对build.gradle从上到下执行的过程就是evaluate过程

使用标准插件时拓展参数的执行流程

  1. 接入的gradle，apply plugin时，在插件内部回调方法apply(Project project)中进行拓展的定义：
mProject.extensions.create('tinkerPatch', TinkerPatchExtension)
  1. 接入的gradle文件，配置拓展参数信息
  2. 插件代码中before/afterEvaluate在闭包中获取用户配置信息
mProject.afterEvaluate {
            def configuration = mProject.tinkerPatch
}

/**
 * 由于一般方式配置拓展的方式，应用端配置的参数只能在afterEvaluate方法中获取配置的参数值，而此时已经无法在进行buildConfig配置tinkerEnable
 * 因此使用ext的拓展方式替代本拓展方式:*/
 ext {
    tinkerPatchEnable = true
    appKey = 'xxx'
}
apply plugin: 'com.xh.xhcore.plugin'

apply plugin方式插件编写流程

  1. 项目new android library module
  2. 只留下src/main和build.gradle，其他的文件全部删除
  3. 注册插件信息，在src/main/resources/META-INF/gradle-plugins/${pluginName}.properties
  4. moudule 进行 apply plugin: “${pluginName}”

插件内部包裹嵌套其他插件

root project的blueScript中配置的classPath的被嵌套的插件仅仅参与本项目的编译，并不会打包在发布的插件里，因此需要在插件build.gradle中添加implementation被嵌套的插件，来确保可以屏蔽被嵌套插件的依赖信息，使得接入方仅仅依赖我们自己的插件就行，无需知道我们内部依赖了哪些插件

参考

https://docs.gradle.org/current/userguide/custom_plugins.html#header

https://guides.gradle.org/testing-gradle-plugins/

https://docs.gradle.org/4.10.3/userguide/test_kit.html

https://docs.gradle.org/4.10.3/userguide/test_kit.html#sec:functional_testing_with_the_gradle_runner

https://github.com/gradle-guides/testing-gradle-plugins/tree/master/samples/code/url-verifier-plugin

Android 黑科技 ｜Gradle Plugin的一些使用场景

packaging a plugin

There are several places where you can put the source for the plugin.

  • Build script

You can include the source for the plugin directly in the build script. This has the benefit that the plugin is automatically compiled and included in the classpath of the build script without you having to do anything. However, the plugin is not visible outside the build script, and so you cannot reuse the plugin outside the build script it is defined in.

  • buildSrc project

You can put the source for the plugin in the *rootProjectDir*/buildSrc/src/main/groovy directory (or *rootProjectDir*/buildSrc/src/main/java or *rootProjectDir*/buildSrc/src/main/kotlin depending on which language you prefer). Gradle will take care of compiling and testing the plugin and making it available on the classpath of the build script. The plugin is visible to every build script used by the build. However, it is not visible outside the build, and so you cannot reuse the plugin outside the build it is defined in.

See Organizing Gradle Projects for more details about the buildSrc project.

  • Standalone project

You can create a separate project for your plugin. This project produces and publishes a JAR which you can then use in multiple builds and share with others. Generally, this JAR might include some plugins, or bundle several related task classes into a single library. Or some combination of the two.