Gradle 4 - 测试依赖于另一个项目的测试

Question

我有以下多项目结构：

/
    build.gradle
    common/
        build.gradle
        src/main/
            resources/common.properties
            java/...
        src/test/
            resources/common.properties
            java/...
    app/
        build.gradle
        src/main/java/...
        src/test/java/...
    admin/
        build.gradle
        src/main/java/...
        src/test/java/...

common项目包含一些常用方法，它们有自己的单元测试和一个CommonDefs类，其中包含从common.properties加载的数据。运行单元测试时，测试资源中的common.properties文件应该覆盖主资源中的文件，并且测试按预期工作。

当运行app和admin项目的单元测试时，问题就开始了 - 这些项目包含来自公共项目的CommonDefs测试。

到目前为止，我已经使用了类似于方法described in the following SO answer的通用解决方案，并且它已经完美地工作了几年。这是根build.gradle包含的内容：

allprojects {
    plugins.withType(JavaPlugin) {
        configurations {
            testOutput
        }

        dependencies {
            testOutput sourceSets.test.output
        }
    }
}

和app/build.gradle＆amp; admin/build.gradle都包含：

dependencies {
    compile project(":common")
    testCompile project(path: ":common", configuration: "testOutput")
    // ...
}

我已经决定是时候升级Gradle了（之前使用的是2.14.1），所以我开始针对Gradle 4.2.1测试项目。现在，每次运行app和admin的测试时，CommonDefs都会从src/main/resources/common.properties而不是src/test/resources/common.properties加载数据。

我已经尝试打印app项目的测试类路径，看起来Gradle 4.2.1首先采用了常见的主JAR：

path\to\app\build\classes\java\test
path\to\app\build\resources\test
path\to\app\build\classes\java\main
path\to\app\build\resources\main
path\to\common\build\libs\common.jar
path\to\common\build\classes\java\test
path\to\common\build\resources\test

使用Gradle 2.14.1，结果是：

path\to\app\build\classes\test
path\to\app\build\resources\test
path\to\app\build\classes\main
path\to\app\build\resources\main
path\to\common\build\classes\test
path\to\common\build\resources\test
path\to\common\build\libs\common.jar

有没有办法告诉较新版本的Gradle优先考虑common的主要输出的测试输出？

N.B

我还尝试在app/build.gradle中使用以下内容：

evaluationDependsOn(":common")

dependencies {
    compile project(":common")
    testCompile project(":common").sourceSets.test.output
}

这似乎有用，但它看起来相当hacky，我想在可能的情况下坚持使用配置的解决方案。