Kotlin 与 Gradle 的安装与初步使用(2)
Kotlin 与 Gradle 的安装与初步使用(2)
前言
在上一个章节中，我们讨论了如何安装 Kotlin 和 Gradle，并使用它们来编写一个简单的 Hello World 程序。
在本章中，我想聊一下 Gradle 的核心概念，以及如何组织一个Gradle + Kotlin 项目。
目的
- Gradle 的工程目录是如何组织的
- Gradle 的核心概念与流程有哪些，与 Maven 有什么区别
- 如何使用 Gradle 来管理 Kotlin 项目
实际内容
Gradle 工程目录结构
基于上一章节已经创建了一个简单的 Gradle + Kotlin 项目，
我们可以查看一下这个项目的目录结构
❯ cd tutorial
❯ tree -L2
.
├── app 1️⃣
│ ├── build
│ ├── build.gradle.kts
│ └── src
├── build 2️⃣
│ └── reports
├── gradle 3️⃣
│ ├── libs.versions.toml
│ └── wrapper
├── gradle.properties 4️⃣
├── gradlew 5️⃣
├── gradlew.bat 5️⃣
├── kls_database.db 6️⃣
└── settings.gradle.kts 7️⃣
8 directories, 7 files
根据上面的目录结构，我们可以看到几个重要的目录和文件：
app目录：这是我们的应用程序代码所在的目录，包含了build.gradle.kts文件和src目录。
我们一般就在这里写编写我们的 kotlin 代码build目录：这是 Gradle 构建输出的目录，包含了构建生成的文件和报告。
每次执行gradle build命令时，Gradle 会在这里生成构建结果gradle目录：这是 Gradle 的配置文件和库的目录，包含了libs.versions.toml文件和wrapper目录。
libs.versions.toml文件用于管理依赖库的版本，wrapper目录包含了 Gradle Wrapper 的相关文件gradle.properties文件：这是 Gradle 的全局配置文件gradlew和gradlew.bat文件：这是 Gradle Wrapper 的脚本文件，用于在不同的操作系统上执行 Gradle 命令。\kls_database.db文件：这是 Kotlin Language Server 的数据库文件，用于存储代码索引和其他信息, 事实上这是个 sqlite 数据库文件，
主要用于 Kotlin Language Server 的代码索引和其他信息存储settings.gradle.kts文件：这是 Gradle 的设置文件，用于定义项目的结构和模块
Gradle 的核心概念与流程
- 项目，在 Gradle 中，一个项目是一个独立的构建单元，通常对应于一个应用程序或库。
在我们的例子中，app目录就是一个项目 - 任务，Gradle 的构建过程是由一系列任务组成的，每 个任务执行特定的操作，如编译代码、运行测试、打包应用等。
任务可以通过build.gradle.kts文件定义 - 依赖，Gradle 支持声明项目的依赖关系，可以是其他项目、库或插件。
依赖可以在build.gradle.kts文件中声明，Gradle 会自动处理依赖的下载和管理 - 插件，Gradle 插件是扩展 Gradle 功能的模块，可以添加新的任务、配置和功能。
插件可以在build.gradle.kts文件中应用，常用的插件包括 Java 插件、Kotlin 插件等 - 构建脚本，Gradle 的构建脚本是用 Groovy 或 Kotlin DSL 编写的，用于定义项目的构建逻辑。
在我们的例子中，build.gradle.kts文件就是一个构建脚本
在这里，build.gradle.kts 文件是 Gradle 的构建脚本，该文件只作用于当前项目（即 app 目录）。
我的意思是说，build.gradle.kts 文件 只定义了 当前项目的构建逻辑，而不是整个 Gradle 工程的构建逻辑。\
与之对应的，区分整个 Gradle 工程的构建逻辑的是 settings.gradle.kts 文件。\
Gradle Wrapper
在上一章节中，我们下载了 Gradle 到本机的同时，在执行 ./gradlew build 命令时，
我们同时还下载了 Gradle 在本项目的 gradle/wrapper 里
同时，我们还使用了 ./gradlwe run 来执行我们的 Kotlin 程序
也就是说，其实我们并没有用到我们本机的 Gradle，而是使用了项目中的 Gradle
而我们通常称项目里的 Gradle 为 Gradle Wrapper
Gradle Wrapper 是 Gradle 的一个特性，它允许我们在项目中包含一个特定版本的 Gradle。
这样，无论我们在什么环境中运行项目，都可以确保使用相同版本的 Gradle，从而避免版本不兼容的问题。
我们再把目光放到 gradle/wrapper 目录中
❯ tree -L2 ./gradle
gradle
├── libs.versions.toml 1️⃣
└── wrapper
├── gradle-wrapper.jar 2️⃣
└── gradle-wrapper.properties 3️⃣
2 directories, 3 files
根据上面的目录结构，我们可以看到几个重要的文件：
libs.versions.toml文件：这是一个版本管理文件，用于定义项目中使用的依赖库的版本。
这个文件可以帮助我们统一管理依赖库的版本，避免版本冲突gradle-wrapper.jar文件：这是 Gradle Wrapper 的核心文件，包含了 Gradle Wrapper 的实现代码，主要用于下载正确的 Gradle 版本gradle-wrapper.properties文件：这是 Gradle Wrapper 的配置文件，用于配置 Gradle 的下载源以及下载包
Gradle 命令使用
其实我个人感觉与 Maven 也有相似之处
首先我们看一下 Gradle 的命令行帮助信息
❯ ./gradlew --help
...
USAGE: gradlew [option...] [task...]
...
❯ ./gradlew tasks
...
其他的都可以忽略了，只需要知道
./gradlew --help可以查看命令的option信息./gradlew tasks可以查看可用的任务列表
根据自己的要求去弄就可以了
我想说的是，在 tasks 的使用上，有点类似于 Maven
❯ mvn clean compile test
❯ gradle clean build
主要区别在于 Maven 的生命周期是固定的，而 Gradle 的任务是可以自定义的。\
值得注意的是，Gradle 面向多个项目的时候，命令的用法会有所区别
❯ ./gradlew build
❯ ./gradlew :build
这两个用法很相似，但也存在一定的区别
./gradlew build这个命令作用于整个 Gradle 项目，
它会执行所有项目的build任务, 我的意思意思是 所有子项目都会执行该命令./gradlew :build这个命令作用于当前项目的build任务，
它只会执行当前项目的build任务, 在这种情况下，：表示当前项目的根目录,也就是只对根项目执行build任务
而如果说我们要指定不同的子项目任务时，假设该子项目为 subproject，
我们可以使用以下命令：
❯ ./gradlew :subproject:build
Settings.gradle.kts 文件
Settings.gradle.kts 文件是 Gradle 的设置文件，用于定义项目的结构和模块。也就是说 \
- 当我们的项目是一个单一的一个项目的时候，这个文件是一个可选项
而当这个项目没有这个文件的时候， Gradle 会默认将当前目录作为一个单一的项目来处理 - 当我们的项目是个多子项目的时候，那么这个文件是必须的
让我们看一看在我们刚新建的项目中，settings.gradle.kts 文件的内容
❯ cat settings.gradle.kts
/*
* This file was generated by the Gradle 'init' task.
*
* The settings file is used to specify which projects to include in your build.
* For more detailed information on multi-project builds, please refer to https://docs.gradle.org/9.0.0-rc-4/userguide/multi_project_builds.html in the Gradle documentation.
*/
plugins {
// Apply the foojay-resolver plugin to allow automatic download of JDKs
id("org.gradle.toolchains.foojay-resolver-convention") version "1.0.0"
}
rootProject.name = "tutorial" 1️⃣
include("app") 2️⃣
rootProject.name = "tutorial"：这行代码设置了根项目的名称为tutorial，
这个名称会在构建输出和报告中使用include("app")：这行代码包含了一个名为app的子项目，
这意味着在构建过程中，Gradle 会处理app目录下的build.gradle.kts文件，并将其作为一个子项目
当然了，这个文件除了定义子项目之外，还可以定义其他的设置，具体如图所示
这里就不多赘述了
build.gradle.kts 文件
在多项目中工程中，每个子项目都拥有自己的 build.gradle.kts 文件，
这个文件主要用于定义子项目的插件以及依赖
基于前面的项目，让我们看一想我们的 build.gradle.kts 文件的内容
❯ cat ./app/build.gradle.kts
/*
* This file was generated by the Gradle 'init' task.
*
* This generated file contains a sample Kotlin application project to get you started.
* For more details on building Java & JVM projects, please refer to https://docs.gradle.org/9.0.0-rc-4/userguide/building_java_projects.html in the Gradle documentation.
*/
plugins { 1️⃣
// Apply the org.jetbrains.kotlin.jvm Plugin to add support for Kotlin.
alias(libs.plugins.kotlin.jvm)
// Apply the application plugin to add support for building a CLI application in Java.
application
}
repositories {
// Use Maven Central for resolving dependencies.
mavenCentral()
}
dependencies { 2️⃣
// Use the Kotlin JUnit 5 integration.
testImplementation("org.jetbrains.kotlin:kotlin-test-junit5")
// Use the JUnit 5 integration.
testImplementation(libs.junit.jupiter.engine)
testRuntimeOnly("org.junit.platform:junit-platform-launcher")
// This dependency is used by the application.
implementation(libs.guava)
}
// Apply a specific Java toolchain to ease working on different environments.
java {
toolchain {
languageVersion = JavaLanguageVersion.of(21)
}
}
application { 3️⃣
// Define the main class for the application.
mainClass = "org.example.AppKt"
}
tasks.named<Test>("test") {
// Use JUnit Platform for unit tests.
useJUnitPlatform()
}
- ‘plugins’ 用于定义项目插件
- ‘dependencies’ 用于定义项目的依赖
- ‘application’ 用于定义应用程序的主类，同行也可以用来定义项目的
tasks
与 Settings.gradle.kts 不同，\
- 在作用域上，
build.gradle.kts文件是每个子项目的构建脚本，而settings.gradle.kts则作用于整个工程 - 在功能上，
build.gradle.kts并不定义pluginManagement, 而Settings.gradle.kts并不能定义项目的具体依赖
总结
在本章中，我们讨论了 Gradle 的核心概念和目录结构，并且对其中的文件有了初步的了解。
下一章节我想说一说如何使用 Kotlin 来编写相关的程序，简单的来实践一下
浙公网安备 33010602011771号