多项目构建中的子项目通常共享一些共同的依赖关系。
Gradle 提供了一个特殊的目录来存储可自动应用于子项目的共享构建逻辑，而不是在每个子项目构建脚本中复制和粘贴相同的 Java 版本和库。
共享逻辑buildSrc
buildSrc是 Gradle 识别和受保护的目录，它具有一些优点：
-
可重用的构建逻辑：
buildSrc允许您以结构化方式组织和集中您的自定义构建逻辑、任务和插件。在 buildSrc 中编写的代码可以在您的项目中重复使用，从而更轻松地维护和共享常见的构建功能。 -
与主构建的隔离：
放置的代码
buildSrc与项目的其他构建脚本隔离。这有助于保持主要构建脚本更清晰并更专注于特定于项目的配置。 -
自动编译和类路径：
该目录的内容
buildSrc会自动编译并包含在主构建的类路径中。这意味着 buildSrc 中定义的类和插件可以直接在项目的构建脚本中使用，无需任何额外的配置。 -
易于测试：
由于
buildSrc是单独的构建，因此它可以轻松测试您的自定义构建逻辑。您可以为构建代码编写测试，确保其行为符合预期。 -
Gradle 插件开发：
如果您正在为您的项目开发自定义 Gradle 插件，那么
buildSrc这是一个存放插件代码的方便位置。这使得插件可以在您的项目中轻松访问。
该buildSrc目录被视为包含的构建。
对于多项目构建，只能有一个buildSrc目录，并且必须位于项目根目录中。
使用它的缺点buildSrc是，对其进行任何更改都会使项目中的每个任务无效并需要重新运行。
|
buildSrc使用适用于 Java、Groovy 和 Kotlin 项目的相同源代码约定。它还提供对 Gradle API 的直接访问。
一个典型的项目包括buildSrc以下布局：
.
├── buildSrc
│ ├── src
│ │ └──main
│ │ └──kotlin
│ │ └──MyCustomTask.kt (1)
│ ├── shared.gradle.kts (2)
│ └── build.gradle.kts
├── api
│ ├── src
│ │ └──...
│ └── build.gradle.kts (3)
├── services
│ └── person-service
│ ├── src
│ │ └──...
│ └── build.gradle.kts (3)
├── shared
│ ├── src
│ │ └──...
│ └── build.gradle.kts
└── settings.gradle.kts| 1 | Create the MyCustomTask task. |
| 2 | A shared build script. |
| 3 | Uses the MyCustomTask task and shared build script. |
.
├── buildSrc
│ ├── src
│ │ └──main
│ │ └──kotlin
│ │ └──MyCustomTask.groovy (1)
│ ├── shared.gradle (2)
│ └── build.gradle
├── api
│ ├── src
│ │ └──...
│ └── build.gradle (3)
├── services
│ └── person-service
│ ├── src
│ │ └──...
│ └── build.gradle (3)
├── shared
│ ├── src
│ │ └──...
│ └── build.gradle
└── settings.gradle| 1 | Create the MyCustomTask task. |
| 2 | A shared build script. |
| 3 | Uses the MyCustomTask task and shared build script. |
在 中，创建了buildSrc构建脚本。shared.gradle(.kts)它包含多个子项目共有的依赖项和其他构建信息：
repositories {
mavenCentral()
}
dependencies {
implementation("org.slf4j:slf4j-api:1.7.32")
}repositories {
mavenCentral()
}
dependencies {
implementation 'org.slf4j:slf4j-api:1.7.32'
}在 中buildSrc，MyCustomTask还创建了 。它是一个辅助任务，用作多个子项目的构建逻辑的一部分：
import org.gradle.api.DefaultTask
import org.gradle.api.tasks.TaskAction
open class MyCustomTask : DefaultTask() {
@TaskAction
fun calculateSum() {
// Custom logic to calculate the sum of two numbers
val num1 = 5
val num2 = 7
val sum = num1 + num2
// Print the result
println("Sum: $sum")
}
}import org.gradle.api.DefaultTask
import org.gradle.api.tasks.TaskAction
class MyCustomTask extends DefaultTask {
@TaskAction
void calculateSum() {
// Custom logic to calculate the sum of two numbers
int num1 = 5
int num2 = 7
int sum = num1 + num2
// Print the result
println "Sum: $sum"
}
}该任务在和项目MyCustomTask的构建脚本中使用。该任务自动可用，因为它是.apisharedbuildSrc
该shared.build(.kts)文件也适用：
// Apply any other configurations specific to your project
// Use the build script defined in buildSrc
apply(from = rootProject.file("buildSrc/shared.gradle"))
// Use the custom task defined in buildSrc
tasks.register<MyCustomTask>("myCustomTask")// Apply any other configurations specific to your project
// Use the build script defined in buildSrc
apply from: rootProject.file('buildSrc/shared.gradle')
// Use the custom task defined in buildSrc
tasks.register('myCustomTask', MyCustomTask)使用约定插件共享逻辑
Gradle 组织构建逻辑的推荐方法是使用其插件系统。
我们可以编写一个插件来封装一个项目中多个子项目通用的构建逻辑。这种插件称为约定插件。
虽然编写插件超出了本节的范围，但构建 Gradle 项目的推荐方法是将通用构建逻辑放入位于buildSrc.
让我们看一个示例项目：
.
├── buildSrc
│ ├── src
│ │ └──main
│ │ └──kotlin
│ │ └──myproject.java-conventions.gradle (1)
│ └── build.gradle.kts
├── api
│ ├── src
│ │ └──...
│ └── build.gradle.kts (2)
├── services
│ └── person-service
│ ├── src
│ │ └──...
│ └── build.gradle.kts (2)
├── shared
│ ├── src
│ │ └──...
│ └── build.gradle.kts (2)
└── settings.gradle.kts| 1 | Create the myproject.java-conventions convention plugin. |
| 2 | Applies the myproject.java-conventions convention plugin. |
.
├── buildSrc
│ ├── src
│ │ └──main
│ │ └──kotlin
│ │ └──myproject.java-conventions.gradle.kts (1)
│ └── build.gradle
├── api
│ ├── src
│ │ └──...
│ └── build.gradle (2)
├── services
│ └── person-service
│ ├── src
│ │ └──...
│ └── build.gradle (2)
├── shared
│ ├── src
│ │ └──...
│ └── build.gradle (2)
└── settings.gradle| 1 | Create the myproject.java-conventions convention plugin. |
| 2 | Applies the myproject.java-conventions convention plugin. |
该构建包含三个子项目：
rootProject.name = "dependencies-java"
include("api", "shared", "services:person-service")rootProject.name = 'dependencies-java'
include 'api', 'shared', 'services:person-service'目录中创建的约定插件源码buildSrc如下：
plugins {
id("java")
}
group = "com.example"
version = "1.0"
repositories {
mavenCentral()
}
dependencies {
testImplementation("junit:junit:4.13")
}plugins {
id 'java'
}
group = 'com.example'
version = '1.0'
repositories {
mavenCentral()
}
dependencies {
testImplementation "junit:junit:4.13"
}约定插件应用于api、shared和person-service子项目：
plugins {
id("myproject.java-conventions")
}
dependencies {
implementation(project(":shared"))
}plugins {
id("myproject.java-conventions")
}plugins {
id("myproject.java-conventions")
}
dependencies {
implementation(project(":shared"))
implementation(project(":api"))
}plugins {
id 'myproject.java-conventions'
}
dependencies {
implementation project(':shared')
}plugins {
id 'myproject.java-conventions'
}plugins {
id 'myproject.java-conventions'
}
dependencies {
implementation project(':shared')
implementation project(':api')
}不要使用跨项目配置
在子项目之间共享构建逻辑的一种不正确的方法是通过和DSL 构造进行跨项目配置。subprojects {}allprojects {}
避免使用subprojects {}和allprojects {}。
|
通过交叉配置，构建逻辑可以注入到子项目中，这在查看其构建脚本时并不明显。
从长远来看，交叉配置通常会变得更加复杂并成为一种负担。交叉配置还可能在项目之间引入配置时耦合，这可能会阻止按需配置等优化正常工作。