为什么要提交给 VCS 的分级包装？

来自 格拉德尔的文件:

此任务生成的脚本旨在提交到 您的版本控制系统。此任务还生成一个小的 JAR 引导 JAR 文件和属性文件 这些脚本委托给这个 JAR。

来自: < a href = “ https://stackoverflow./questions/1273921/What-should-NOT-be-under-source-control”> 什么不应该在源代码控制之下？

我认为 生成的文件不应该在 VCS 中。

什么时候需要 gradlew和 gradle/gradle-wrapper.jar？

为什么不在 build.gradle文件中存储 等级版本？

55095 次浏览
小开

因为gradle包装器的全部意义在于，不需要安装gradle，甚至不知道它是如何工作的，从哪里下载，哪个版本，就可以从VCS中克隆项目，执行它包含的gradlew脚本，无需任何额外步骤就可以构建项目。

如果你所拥有的只是一个gradle版本号。gradle文件，你将需要一个README解释每个人，gradle版本X必须从URL Y下载和安装，你将不得不这样做，每次版本是增量。

小开

因为Gradle包装器的全部意义在于，在没有安装过Gradle的情况下

JDK也是一样，你也想提交吗?你是否也提交了所有的依赖库?

随着新版本的发布，依赖关系应该不断升级，以获得安全性和其他错误修复，因为如果您远远落后于更新，那么再次更新将是一项非常耗时的任务。

如果Gradle包装器为每个新版本都增加，并且被提交，那么回购将变得非常大。在使用分布式VCS时，这个问题很明显，因为克隆会下载所有版本的所有内容。

甚至不知道它是如何运作的

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

从哪里下载，哪个版本

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

对于Gradle版本>= 5:

wrapper {
gradleVersion = 'X.X'
}

然后

gradle wrapper

下载正确的版本。

从VCS中克隆项目，执行其中包含的gradlew脚本，无需任何额外步骤即可构建项目。

通过上述步骤解决。下载Gradle包装器与下载其他依赖没有什么不同。脚本可以非常智能地检查当前的Gradle包装器，只有在有新版本时才下载它。

如果开发人员以前从未使用过Gradle，可能不知道项目是用Gradle构建的，那么运行build.sh比运行gradlew build更明显。

如果你所拥有的只是一个gradle版本号。你需要一个README解释每个人gradle版本X必须从URL Y下载并安装，

不，您不需要README。你可以有一个，但我们是开发人员，我们应该尽可能地自动化。创建脚本更好。

每次版本增加的时候都要这样做。

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

  1. 克隆回购
  2. 运行构建脚本

然后升级到最新的Gradle包装是没有问题的。如果自上次运行以来版本增加了，脚本可以下载新版本。

小开

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

在项目的README中，说明安装步骤是必需的，即:

gradle wrapper --gradle-version 3.3

这适用于Gradle 2.4或更高版本。这将创建一个包装器，而不需要将专用任务添加到“build.gradle”中。

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

  • 。/它
  • gradlew
  • gradlew.bat

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

小开

什么是“项目”?

也许这个习惯用法的技术定义不包括构建脚本。但是如果我们接受这个定义，那么我们必须说你的“项目”并不是你需要版本化的所有东西!

但如果我们说“your project”是一切you have done。然后我们可以说你必须将它，只有它包含到VCS中。

这是非常理论性的，在我们的开发工作中可能并不实际。因此我们将其更改为"你的项目是每个文件(或文件夹)，你需要直接编辑它们"。

“直接”表示“不是间接”，“间接”表示通过编辑另一个文件，然后一个效果将反映到这个文件。

所以我们得到了OP所说的(并且是在这里):

我认为生成的文件不应该在VCS中。

是的。因为你还没有创建它们。所以根据第二种定义，他们不是“你的项目”的一部分。

这些文件的结果是什么:

  • < p > build.gradle:是的。我们需要编辑它。我们的作品应该有版本。

    注意:在哪里编辑没有区别。无论是在你的文本编辑器环境还是在项目结构 GUI环境中。不管怎样你做它直接< em > < / em >!< / p >

  • < >强gradle-wrapper。< / >强属性:是的。我们至少需要在这个文件中确定Gradle版本。

  • gradle-wrapper.jar和gradlew[.bat]:我还没有在我的任何开发作品中创建或编辑它们，直到这一刻!所以答案是“不”。如果你这样做过，那么关于你在那份工作(以及你编辑的同一份文件)的答案是“是的”。

关于最新病例的重要提示是克隆你的回购的用户，需要在回购的<root-directory>到自动生成包装文件上执行这个命令:

> gradle wrapper --gradle-version=$v --distribution-type=$distType

$v和$distType由gradle-wrapper.properties确定:

distributionUrl=https\://services.gradle.org/distributions/gradle-{$v}-{$distType}.zip

更多信息请参见https://gradle.org/install/。

gradle可执行文件是本地发行版中的bin/gradle[.bat]。不要求本地分配与回购中确定的相同。包装文件创建后，gradlew[.bat]可以自动下载确定的Gradle发行版(如果本地不存在)。然后他/她可能必须使用上述指令使用新的gradle可执行文件(在下载的发行版中)重新生成包装器文件。

注意:在上面的说明中，假设用户有至少一个 Gradle局部分布(例如~/.gradle/wrapper/dists/gradle-4.10-bin/bg6py687nqv2mbe6e1hdtk57h/gradle-4.10)。它涵盖了几乎所有的真实案例。但如果用户还没有任何分布会发生什么?

他/她可以使用.properties文件中的URL手动下载它。但是如果他/她没有在包装器所期望的路径中定位它，包装器将再次下载它!预期路径是完全可预测的，但不在主题范围内(最复杂的部分请参阅在这里)。

也有一些更简单(但肮脏)的方法。例如，他/她可以从任何其他本地/远程存储库复制包装文件(除了.properties文件)到他/她的存储库，然后在他/她的存储库上运行gradlew。它会自动下载合适的发行版。

小开

根据Gradle文档，将gradle-wrapper.jar添加到VCS是预期，因为让开发者可以使用Gradle Wrapper是Gradle方法的一部分:

要使Wrapper文件对其他开发人员和执行环境可用，您需要将它们检入版本控制。包括JAR文件在内的所有包装器文件都非常小。需要将JAR文件添加到版本控制中。有些组织不允许项目向版本控制提交二进制文件。目前，这种方法没有其他选择。

小开

老问题，新答案。如果你不经常升级gradle(我们大多数人都不)，最好把它提交给vc。对我来说，主要原因是为了提高CI服务器上的构建速度。现在，大多数项目都是由CI服务器构建和安装的，每次都是不同的服务器实例。

如果您不提交它，CI服务器将为每次构建下载一个jar，这将显著增加构建时间。还有其他方法可以处理这个问题，但我发现这种方法最容易维护。


提交答案