翻译自《gradle-vs-gradlew-difference》
使用 Gradle
的开发者最常问的问题之一便是: gradle
和 gradlew
的区别?。
这两个都是应用在特定场景的 Gradle 命令。通过本篇文章你将了解到每个命令干了什么,以及如何在两个命令中做选择。
快速摘要
如果你正在开发的项目当中已经包含
gradlew
脚本,安啦,可以一直使用它。没有包含的话,请使用gradle
命令生成这个脚本。想知道为什么吗,请继续阅读。
如果你从 Gradle 官网(https://gradle.org/releases)下载和安装了 Gradle 的话,你便可以使用安装在 bin 路径下的 gradle 命令了。当然你记得将该 bin 路径添加到设备的 PATH 环境变量中。
此后,在终端上运行 gradle
的话,你会看到如下输出:
你会注意到输出里打印了 Gradle 的版本,它对应着你运行的 gradle 命令在设备中的 Gradle 安装包版本。这听起来有点废话,但在谈论 gradlew 的时候需要明确这点,这很重要。
通过这个本地安装的 Gradle,你可以使用 gradle 命令做很多事情,包括:
gradle init
命令创建一个新的 Gradle 项目或者使用 gradle wrapper
命令创建 gradle wrapper 目录及文件gradle build
命令进行 Gradle 编译gradle tasks
命令查看当前的 Gradle 项目中支持哪些 task上述的命令均使用你本地安装的 Gradle 程序,无论你安装的是什么版本。
如果你使用的是 Windows 设备,那么 gradle 命令等同于 gradle.bat,gradlew 命令等同于 gradlew.bat,非常简单。
gradlew
命令,也被了解为 Gradle wrapper
,与 gradle 命令相比它是略有不同的。它是一个打包在项目内的脚本,并且它参与版本控制,所以当年复制了某项目将自动获得这个 gradlew 脚本。
“可那又如何?”
好吧,如果你这么想。让我告诉你,它有很多重要的优势。
gradlew 脚本不依赖本地的 Gradle 安装。在设备上第一次运行的时候会从网络获取 Gradle 的安装包并缓存下来。这使得任何人、在任何设备上,只要拷贝了这个项目就可以非常简单地开始编译。
这个 gradlew 脚本和指定的 Gradle 版本进行绑定。这非常有用,因为这意味着项目的管理者可以强制要求该项目编译时应当使用的 Gradle 版本。
Gradle 特性并不总是互相兼容各版本的,所以使用 Gradle wrapper 可以确保项目每次编译都能获得一致性的结果。
当然这需要编译项目的人使用 gradlew 命令,如下是在项目内运行 ./gradlew
的示例:
输出和运行 gradle
命令的结果比较相似。但仔细查看你会发现版本不一样,不是上面的 6.8.2
而是 6.6.1
。
这个差异说重要也重要,说不重要也不重要。
但当使用 gradlew 的话可以免于担心由于 Gradle 版本导致的不一致性,缘自它可以保证所有的团队成员以及 CI 服务端都会使用相同的 Gradle 版本来构建这个项目。
另外,几乎所有使用 gradle
命令可以做的事情,你也可以使用 gradlew
来完成。比如编译一个项目就是 ./gradlew build
。
如果你愿意的话,可以拷贝 示例项目 并来试一下gradlew
。
至此你应该能看到在项目内使用 gradlew
通常是最佳选择。确保 gradlew 脚本受到版本控制,这样的话你以及其他开发者都可以收获如上章节提到的好处。
但是,难道没有任何情况需要使用 gradle
命令了吗?当然有。如果你期望在一个空目录下搭建一个新的 Gradle 项目,你可以使用 gradle init
来完成。这个命令同样会生成 gradlew 脚本。
(如下的表格简单列出两者如何选)可以说,使用 gradlew 确实是 Gradle 项目的最佳实践。
你想做什么? | gradle 还是 gradlew? |
---|---|
编译项目 | gradlew |
测试项目 | gradlew |
项目内执行其他 Gradle task | gradlew |
初始化一个 Gradle 项目或者生成 Gradle wrapper | gradle |
https://tomgregory.com/gradle-vs-gradlew-difference/