第十三天：初探 Gradle Build Script

对於一个 Gradle 专案来说，一切设定与运作的核心都纪录在 Build Script 里。为了让我们更了解 Gradle，今天就来了解一下 Build Script 的基本架构及常见设定。

Gradle Build Script

Gradle 的 Build Script 最少由两个档案组成，build.gradle[.kts] 及 settings.gradle[.kts]。虽然 Gradle 核心是用 Java 撰写，但为了提供更好的扩充介面，Gradle 提供了 DSL 语法，让开发者能用简洁、更具语义的方式来扩充 Gradle。Gradle 一开始选 Groovy 做 DSL，而当 Kotlin 出现後，Gradle 也顺势增加了对 Kotlin DSL 的支援。所以在建立专案的时候，Gradle 会问您想用哪种语言写 DSL。假如选 Groovy，则 Build Script 的档名就是 build.gradle；假如选 Kotlin，则档名後面就会多一个 .kts，意思是指用 Kotlin Script 来执行。

一个观念可以先放在心上，build.gradle.kts 会对应到 org.gradle.api.Project；而 settings.gradle.kts 则是对应到 org.gradle.api.initialization.Settings。在这个系列里，我们会全程使用 Kotlin DSL 来写 Build Script。

三大常见区块

我们把前面练习专案的 build.gradle.kts 打开来看一下，其中 plugins、repositories、dependencies 这三个区块的设定是最常见的，因为是以 Kotlin DSL 的语法实作，所以看起来会很像呼叫 Lambda：

plugins {
    // ...
}

repositories {
    // ...
}

dependencies {
    // ...
}

plugins

全面有提到 Gradle 运作的基本单元是任务（Task），Gradle 内建就有提供一些基本任务供我们使用，不够时 Gradle 也支援撰写客制化任务来扩充，当我们想重复利用这些客制化任务时，就可以把它们抽取出来独立成一个 Plugin。

Gradle 官方也提供 Gradle Plugin Portal 供开发者将自己的 Plugin 发表在这个平台上，Plugin 的使用者也可以很方便的在上面查询 Plugin 的详细资料。以我同事发表的 Docker Plugin 为例，您可以在网页上查到该 Plugin 的版本、原始码位置以及如何将 Plugin 套用到 Build Script 的语法：

plugins {
  id("org.jetbrains.gradle.docker") version "1.1.7"
}

repositories

一个专案使用到的相依套件有可能来自不同的储存库，repostiory 区段可以让我们指定当 Gradle 要抓相依套件时，要去哪些储存库抓？以目前来说，最主要的储存库应该就是 Maven Central。当然，您也可以用自定的储存库，比方说 JetBrains 的 Space 就支援提供与 Gradle 相容的储存库存放机制。

dependencies

当我们要描述当前专案有用到哪些第三方相依套件时，就是纪录在 dependencies 区段里。在这个区段里应该会常看到两种宣告方式，一种是 implementation、另一种是 testImplementation。

implementation 表示该相依套件在编译时要被一并使用，但 testImplementation 则表示只有在运行测试的时候需要被一起编译，也就是说，通常会使用这种方式宣告的都是跟测试有关的套件或框架。

在宣告相依套件时，需要指定套件的三个资讯：Group、Name、Version，我们可以将这三个资讯以 : 连接成一个字串表示。以 Kotest 这个测试框架里的 io.kotest:kotest-runner-junit5:4.6.3 套件为例，io.kotest 就是 Group、kotest-runner-junit5 就是 Name、4.6.3 就是 Version。当我们在查询套件资讯的时候，我会推荐大家到 Maven Central 网站上输入自己想要查询的套件名称，选择好版本进到详细页面後，这个网站就会把所有 Build Tool 的各种语法都显示在右边，可以直接 Copy-Paste 回来即可。

参考资料

• Gradle Plugin Portal