Question

这个问题对我来说似乎是个谜。我们正在开发一个Spring REST应用程序。在我的团队中，我们让Jenkins在所有签到（CI构建）上运行构建。此外，还有一个官方建筑，每晚都在做。最近在CI构建期间，一些集成测试开始失败，我们追查了jar冲突的原因。但是，我们已经成功地排除了导致这些冲突的传递依赖关系，对于官方构建，以及团队中的一些开发人员，这仍然是正确的。对于其他人，它不再是。

我们拥有相同的代码库和相同的Gradle文件。当我在我的系统上运行依赖任务时，我在一个子项目中有一个很长的传递依赖树（和Jenkins机器一样），而其他人没有这样的树。此外，对于某些开发人员而言，WAR的大小比其他开发人员大几个数量级。传递依赖性来自另一个上传到Nexus的相关项目。

我已经在我的机器和Jenkins机器上刷新了依赖关系，甚至消灭了.gradle，但无济于事。

这听起来像环保，但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 /测试/ 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用户主文件夹和项目文件夹中具有相同的gradle.properties。

Answer 3

首先，感谢快速回复，但我有更新：

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

执行后者可以解决问题。从Nexus下载（正如Jenkins所做的那样，并且你应该能够做到）允许问题发生，暴露它。我不相信这会影响构建顺序，但它会影响所引入的传递依赖性。

各个子项目的依赖关系也存在一些问题：例如，一个不打算依赖项目的项目就有一个问题，而一个项目是带来传递依赖关系的罪魁祸首。因此，当该基础项目被其他项目引入时，它会产生连锁反应。其中一些依赖块需要清理。

再次感谢您的回复！

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

3 个答案: