1.前言

本系列主要讲的是Gradle build Tool的理论与实践，也就是我们常说的Gradle，与Maven类似，它也是一种自动化构建工具。相对于Maven来说，Gradle在可定制型、灵活性、性能、插件生态、多项目管理上面有更多的优势，同时相对于XML语言，Gradle使用代码来做管理声明方式会更加优雅。缺点是学习的曲线更陡、资源消耗更高、维护成本更高等。

总之，Gradle 更适合复杂和大型项目，尤其是需要高度定制化的构建过程的项目。它的灵活性、性能优化和现代化的 DSL 使得它在这些场景中更具优势。

此外，有时在工作中接手的维护项目可能就是通过Gradle在组织构建的，这也是一个不得不学习Gradle的理由。

在本系列中涉及的Gradle版本是8.x，有一定基础和英语阅读能力的同学，建议阅读《Gradle官方文档》。在这个系列中，涉及到的中央仓库使用的是maven的仓库及其镜像，感兴趣的话，可以关注我的《Maven专栏》，里面从理论到实践的文章都有。

---

本篇将会通过IDEA创建一个单体demo项目，以此来介绍Gradle的项目解决，以及其中的核心概念。

2.项目初始化及核心概念

Gradle可以通过命令行来进行初始化，通过gradle init指令，按照提示一步一步操作即可，感兴趣的话可以自行查看文档。在开发中更方便的方式是直接通过IDEA进行创建，这种方式不需要安装gradle环境。

2.1.在IDEA中创建gradle项目

打开New Project弹窗，在BuildSystem中选择Gradle，并指定项目文件路径、GroupId、ArtifactId，即可创建一个Gradle项目

创建好的标准项目结构如下：

2.2.gradle-wrapper

首先看Gradle Wrapper ，它是用来确保项目在任何环境中Gradle版本相同的一种机制。无论是不同开发者的本地环境、还是测试环境、生产环境，都能避免由于版本差异带来的一些兼容性问题。

2.2.1.gradle-wrapper的作用

使用gradle-wrapper的好处主要就是方便，可以减少沟通成本和配置成本，例如：

• 一致性：就是上面说到的，各个环节的gradle版本一致
• 简化开发环境：开发的时候不需要本地安装gradle
• 自动下载：按配置文件 (gradle-wrapper.properties)中的下载地址和版本信息，自动下载指定版本的gradle并应用。
• CICD：因为不需要手动去处理gradle，简化了持续集成的配置。

2.2.2.gradle-wrapper的初始化与配置

上面是通过IDEA创建的项目，在当前版本已经默认包含了Gradle Wrapper，如果在一些其他的项目中没有自动创建的话可以通过指令来创建（需要gradle环境）。

gradle wrapper

在项目中生成一些必要的文件和目录，包括：

• gradlew：Unix 系统上的 Wrapper 可执行脚本。
• gradlew.bat：Windows 系统上的 Wrapper 可执行脚本。
• gradle/wrapper/gradle-wrapper.jar：Wrapper 的实现文件。
• gradle/wrapper/gradle-wrapper.properties：配置文件，指定 Gradle 版本和下载 URL。

下面是gradle-wrapper.properties中的内容：

distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-8.2-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists

其他的内容可以暂时先不管，重点关注 distributionUrl，这个字段就是配置了指定版本的gradle下载地址。不过这是一个国外的地址，国内访问不太稳定，有时候会出现无法下载的情况，可以配置为镜像地址，例如腾讯提供的地址：《腾讯gradle镜像地址》。

在里面可以看到gradle的版本列表，我们选一个相同的版本修改一下：

distributionUrl=https\://mirrors.cloud.tencent.com/gradle/gradle-8.2-bin.zip

在配置完成之后，使用gradlew (Windows中是gradlew.bat) 脚本构建项目，就可以触发gradle8.2的自动下载与代码的构建，如下图：

在IDEA中，也可以直接使用右侧的刷新按钮触发下载：

---

总之，Gradle Wrapper 是一个强大的工具，用于确保项目在任何环境中都能使用一致的 Gradle 版本进行构建。但它也存在一定的弊端，即不同的项目配置文件中配置的版本不一致的话，在开发环境中就会下载各种各样的gradle版本，会占用硬盘空间。

但可以通过规范各个项目的版本号来解决这个问题，相对与它带来的好处来说，可以忽略不计。

2.3.setting.gradle

这个文件主要是用来定义项目的命名，以及在多项目构建中配置项目的层次结构，在gradle的生命周期中，初始化阶段就会先在项目的根目录中寻找setting.gradle文件，找到之后会按照文件中配置的项目，进行构建流程。

就是下面的那个样子（本篇不涉及到多项目构建，这里只是提一下）。

rootProject.name = 'gradle-demo'

inclue('sub-project')

2.4.build.gradle

build.gradle 是 Gradle 构建系统中的最核心配置文件，用来定义项目的构建过程、依赖管理、插件配置等。下面是基本结构：

plugins {
    id 'java'
}

group = 'com.ls'
version = '1.0-SNAPSHOT'

repositories {
    mavenCentral()
}

dependencies {
    testImplementation platform('org.junit:junit-bom:5.9.1')
    testImplementation 'org.junit.jupiter:junit-jupiter'
}

test {
    useJUnitPlatform()
}

2.4.1.plugins

plugins {
    id 'java'
}

这个块用于声明和应用 Gradle 插件，在上面的文件中声明了一个 Java插件，为项目添加了标准的 Java 构建任务和配置。包括：

• 编译 Java 源代码
• 生成 JAR 文件
• 执行单元测试
• 管理依赖项

---

2.4.2.版本定义

group = 'com.ls'
version = '1.0-SNAPSHOT'

这里定义了当前项目的版本号，熟悉maven的同学肯定已经发现了，定义里面缺少了ArtifactId，这是因为gradle的构件Id是隐式定义的，默认使用项目名。

2.4.3.仓库配置

repositories {
    mavenCentral()
}

这里表示配置的仓库为中央仓库，当然这也是一个国外的仓库，会有下载不稳定、下载慢的问题。可以定义多个仓库，按顺序访问，例如：

repositories {
    mavenLocal() // 首先查找本地 Maven 仓库
    maven {
        allowInsecureProtocol = true
        url 'http://nexus.company.com/repository/maven-releases' // 公司私服
        credentials {
            username 'your-username'
            password 'your-password'
       }
    }
    maven {
        url 'https://maven.aliyun.com/repository/public' // 阿里云的 Maven 中央仓库镜像
    }
    mavenCentral() // 最后查找 Maven 中央仓库
}

• mavenLocal：Maven本地仓库
  如果本地已经配置好了Maven运行环境，可以优先使用本地的环境（常见于开发环境中既有Maven项目，又有gradle项目的情况）。

• 公司私服配置：
  这里有一个allowInsecureProtocol 需要注意，如果公司的私服没有使用https，则需要使用这个选项让gradle忽略不安全的网络协议。
  一般来说，这里需要配置好私服地址，主要是用于下载私服中的依赖jar包。但credentials 不是必要的，只有在需要推送jar包到私服的时候才会使用到。而且在本地的Maven配置中如果已经配置了私服的密钥，这里也不需要配置，推送jar的时候会使用maven中配置的密钥。

2.4.4.依赖管理

dependencies {
    testImplementation platform('org.junit:junit-bom:5.9.1')
    testImplementation 'org.junit.jupiter:junit-jupiter'
}

这里是声明项目需要依赖的包，在创建好的项目中引入了junit做单元测试，这里的testImplementation表示，这些依赖仅在编译和执行测试时需要。不会被包含在最终的应用程序包中。

如果想引入Spring的jar包也非常简单，只需要在dependencies通过implementation引入：

implementation 'org.springframework:spring-core:5.3.20'

可以看到的是，通过两个冒号把依赖分成了3个部分，从左到右依次为groupId,artifactId,version

---

更多的情况下，我们不会直接在build.gradle中写死jar包的版本号（特别是在多子项目中），一般是通过gradle.properties来集中管理配置信息，其中就包括版本号。

首先在根目录中创建一个gradle.properties文件，并编辑：

然后修改build.gradle替换为资源文件中配置的key，如下：

 implementation "org.springframework:spring-core:${springCoreVersion}"

---

在依赖管理中，implementation 只是做了最简单的jar包引入操作，还有很多其他的依赖配置（如：api,annotationProcessor等），会在后续的文章中继续讲解。

3.总结

本篇主要讲述了使用gradle创建一个简单的单体项目，并讲解了其中的核心概念，通过本篇的讲解，对gradle会有一个基本的认识，但想要完成项目的构建还不够。在下一篇文中会讲解依赖管理中不同的依赖配置对应的功能及其区别，同时会创建多子项目的项目，来体验一下实际的工作环境是如何构建出来的。