上下文
我有一个项目（A）依赖于另一个项目（B），两者都使用Gradle构建系统。项目A通常声明对B的特定版本的依赖。当修改项目B时，可以很方便地立即看到对项目A的影响。在命令行上使用settings.gradle或--include-build中的includeBuild，项目A的构建被重新配置为包括项目B的本地开发版本，而不是发布的工件（“复合构建”）。但是，项目B的这个本地副本声明了一个开发版本号，而不是项目A所请求的稳定发布版本号。为了确保包含的B的构建满足A中声明的依赖关系，我一直在更改A，以请求像org.example:B:[v6, )这样的版本范围，而不是org.example:B:v6.0。然而，我看到即使A指定了与B不对应的无意义的版本号，构建也会成功。
提问
版本如何影响这个依赖替换过程？
调研
我读过的文档（链接如下）展示了如何包含构建，但没有提到版本号。https://docs.gradle.org/current/userguide/composite_builds.html#defining_composite_builds
本页可能会提供一些提示，涵盖依赖项解析的“蛮力”修改：
在复合构建中，不应用必须与请求的依赖项属性精确匹配的规则：使用复合时，Gradle将自动匹配请求的属性。换句话说，这意味着如果包含另一个构建，则将用包含的构建中的等效变体替换被替换模块的所有变体。
尽管这涉及到“变体”及其“属性”，根据dependency terminology documentation，这似乎与模块版本控制不同，但这条语句似乎是相关的。依赖模块的版本也可以有类似的说法吗？
1条答案
按热度按时间aij0ehis1#
回答：很可能不是...？
在这一页上写着（强调我的）：
Gradle将检查包含的构建中项目的组和名称，并将项目依赖项替换为匹配${project.group}的任何外部依赖项：${project.name}。
类似地，在this page上（强调我的）：
Gradle将检查包含的构建中项目的组和名称，并将项目依赖项替换为任何匹配的外部依赖项。
这些是我能找到的关于这个主题的唯一引用，不幸的是，这些引用很模糊。我们可以告诉的是，substitution 与 group和name 一起使用，而单词 version 没有被提及。事实上，正如你和我所做的经验测试，我们知道指定版本没有任何相关性。
我们不希望版本有任何影响。
想想这个🤔就有道理了.替换是从本地源-隐式地，然后，不断发展的开发者版本，或修补的一个。但肯定不是来自二进制版本。
这是我们有意识的选择。因为我们用include-local-build指令指定了替代，并且我们得到了我们所要求的。如果我们希望版本有意义，那么我们就不要替换，瞧，Gradle将不得不出去获取版本化的二进制版本。
And it will never matter.
更进一步-Gradle是否可以以不同的方式工作？我很怀疑。因为源代码中指定的版本本质上是不可靠的。这是我们最后构建和发布的版本，还是我们计划发布的下一个版本？也许Gradle应该能够跟踪本地文件系统更改，并以某种方式启发式地验证版本！😂😂🤯
从版本到实际源代码的唯一Map是Git标记。这打开了一扇通往复杂性的大门️