Gradle 生态系统分析

Gradle 进阶 第三篇

破山中贼易，破心中贼难

Gradle Convention and Extension

接着上文所说的 DynamicSystem，这一节会进而引入 Convention and Extension 的概念，继续扩展整个系统的灵活性，在 Gradle 的 api 官网里有直接介绍 Extension 相关的 https://docs.gradle.org/current/dsl/org.gradle.api.plugins.ExtensionAware.html，
但是没有讲解关于 Convention 相关的。
Convention 的字面意思是指约定，而 Extension 的字面意思是扩展，从 Gradle 源码来看，Gradle 把这两者变成了一个有机的结合。节选 DefaultProject 类里的一段源码：

    @Override
    public ExtensionContainerInternal getExtensions() {
        return (ExtensionContainerInternal) getConvention();
    }

可以看到其实外部 get 到的 Extension 其实就是 Convention，我对于这段代码的理解是：只要对内满足一定的约定，可以被 Gradle 系统识别的一些 code，其实就是对整个系统的一种扩展。
这个是怎么用的呢，我在这里节选一段 JavaBasePlugin 的代码一作试例：

 private JavaPluginConvention addExtensions(final ProjectInternal project) {
        ...
        project.getConvention().getPlugins().put("java", javaConvention);
        project.getExtensions().create(JavaPluginExtension.class, "java", DefaultJavaPluginExtension.class, javaConvention, project, jvmPluginServices, toolchainSpec);
        project.getExtensions().add(JavaInstallationRegistry.class, "javaInstalls", javaInstallationRegistry);
        project.getExtensions().create(JavaToolchainService.class, "javaToolchains", DefaultJavaToolchainService.class, getJavaToolchainQueryService());
        return javaConvention;
    }

我们看到 JavaBasePlugin 通过添加了一些 Extensions 扩展了 Gradle。或者说对于 Gradle apply 的 Plugin，其实 Gradle 并没有完全定义这些 Plugin 的一些配置行为，但是 Convention 可以完成对于自定义 Plugin 的进行配置，是 Plugin 可以正常工作的基石。

在继续介绍之前我先把先关的两个接口展示一下：

/**
 * Allows adding 'namespaced' DSL extensions to a target object.
 */