为什么Gradle Wrapper应该提交给VCS？

因为gradle包装器的整个要点是能够的,没有安装过gradle

对于JDK也有同样的论点,你也想提交它吗？你是否也提交了所有的依赖库？

随着新版本的发布,应该不断升级依赖项.获取安全性和其他错误修复.而且,如果你远远落后于它,那么再次更新可能是一项非常耗时的任务.

如果每个新版本的gradle包装器递增,并且它已提交,则repo将变得非常大.使用分布式VCS时,问题很明显,克隆将下载所有版本的所有版本.

,甚至不知道它是如何工作的

创建一个构建脚本,下载包装器并使用它来构建.每个人都不需要知道脚本是如何工作的,他们需要同意通过执行它来构建项目.

,从哪里下载,哪个版本

task wrapper(type: Wrapper) {
 gradleVersion = 'X.X' 
}

然后

gradle wrapper

要下载正确的版本.

,从VCS克隆项目,执行它包含的gradlew脚本,并构建项目,无需任何额外步骤.

解决了上述步骤.下载gradle包装器与下载任何其他依赖项没有什么不同.该脚本可以智能检查任何当前的gradle包装器,只有在有新版本时才下载它.

如果开发人员之前从未使用过Gradle,可能不知道该项目是使用Gradle构建的.然后,与运行"gradlew build"相比,运行"build.sh"更为明显.

如果你所拥有的只是build.gradle文件中的gradle版本号,那么你需要一个README来解释所有必须从安装的URL Y下载gradle版本X的人,

不,你不需要自述文件.你可以有一个,但我们是开发人员,我们应该尽可能自动化.创建脚本更好.

每次版本增加时你都必须这样做.

如果开发人员同意正确的流程是:

克隆回购

运行构建脚本

然后升级到最新的gradle包装器没问题.如果自上次运行后版本增加,则脚本可以下载新版本.

我想推荐一个简单的方法.

在项目的自述文件中,记录需要安装步骤,即:

gradle wrapper --gradle-version 3.3

这适用于Gradle 2.4或更高版本.这将创建一个包装器,而无需将专用任务添加到"build.gradle".

使用此选项,忽略(不签入)这些文件/文件夹以进行版本控制:

./gradle

gradlew

gradlew.bat

关键的好处是您不必将下载的文件签入源代码控制.安装需要额外一步.我认为这是值得的.

因为gradle包装器的整个要点是能够的,没有安装gradle,甚至不知道它是如何工作的,从哪个版本下载它,从VCS克隆项目,执行gradlew脚本吧包含,并且无需任何额外步骤即可构建项目.

如果您拥有的只是build.gradle文件中的gradle版本号,那么您需要一个README来解释每个必须从URL Y下载并安装gradle版本X的所有人,并且每次增加版本时都必须这样做.