相同的Gradle文件，相同的代码库，不同开发人员的不同依赖图

Question

这个问题对我来说似乎是一个真正的谜。我们正在制作春季休息应用程序。在我的团队中，我们让Jenkins在所有Checkins（CI构建）上进行构建。此外，每晚都有正式的构建。最近在CI构建期间，一些集成测试开始失败，我们将原因追溯到冲突。但是，我们已经成功地排除了较早造成冲突的及时依赖性，对于正式构建，对于团队中的某些开发人员而言，这仍然是事实。对于其他人来说，它不再是。

我们具有相同的代码库和相同的gradle文件。当我在系统上运行依赖关系任务时，我在一个子标记中有一棵长长的依赖性树（Jenkins Machine也是如此），而其他人则没有这样的树。此外，对于某些开发人员而言，战争的规模比其他开发商大的订单大。传递依赖关系来自上传到Nexus的另一个相关项目。

我在我的机器和詹金斯机器上都有刷新的依赖性，甚至消失了。

这听起来像是环境的，但是Gradle版本和Java版本大致相同，最多有几个次要版本。

关于可能导致这种差异的什么想法？

Answer 1

您可以将依赖性强加于整个特定版本

def gsonModule = 'com.google.code.gson:gson'
configurations.all {
    resolutionStrategy {
        // add dependency substitution rules
        dependencySubstitution {
            substitute module(gsonModule) with module("$gsonModule:2.6.1")
        }
    }
}
// note: configurations block must be above the dependencies
// or build will error
dependencies {
    compile "$gsonModule:2.7"
}

然后，当任何开发人员/CI/TEST/CD运行构建时，您的resolutionStrategy力量一致性在所有汇编中。Gradle中的默认行为是在版本冲突上使用的，将使用较新版本。无论其声明版本如何，这都会迫使所有版本。

$ ./gradlew dependencies --configuration compile -q
------------------------------------------------------------
Root project
------------------------------------------------------------
compile - Dependencies for source set 'main'.
--- com.google.code.gson:gson:2.7 -> 2.6.1

参考：https：//docs.gradle.org/current/dsl/org.gradle.api.artifacts.resolutionstrategy.html

Answer 2

您应该使用gradle包装器来确保整个gradle版本，以便排除某种可能性。

另外，将--refresh-dependencies添加到Gradle命令行。可能是您的某些依赖项未正确版本，并且此标志每次仅拉出最新的依赖项。

最后，查看结果不同的工作站，并确保您的Gradle相同。

Answer 3

首先，感谢您的快速响应，但我有一个更新：

简而言之，我的一位同事确定了其中一个问题。我无法详细介绍，但是Gradle文件具有便利功能，可以从Nexus下载另一个项目（例如我上面提到的相关项目），或者如果存在的本地构建的工件。

执行后者解决了问题。从Nexus下载（就像Jenkins所做的那样，并且您应该做的那样）允许出现问题，并将其暴露出来。我不认为这会影响构建顺序，但确实会影响被拉入的传递依赖性。

在各种子项目的依赖性中也存在一些问题：例如，一个旨在不具有依赖性的项目具有一个，而一个项目是带来传递依赖性的巨大罪魁祸首。因此，当其他项目将基本项目提取时，它会产生连锁反应。其中一些依赖性块需要清理。

再次感谢您的回复！