Gradle resolves version conflict but use wrong version

Old Forum Archive Bugs
1

Gradle: 2.4, 2.5, 2.6
The following project defines subproject ‘submodule’ and task 'test’
submodule redefines dependency commons-lang3 and uses it.
Gradle correctly resolves redefined dependency (version 3.4) but uses version 3.1
It’s exprected that gradle will use version 3.4 and no error is printed.

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'org.apache.commons:commons-lang3:3.1'
    }
}

project('submodule') {
    buildscript {
        repositories {
            mavenCentral()
        }
        dependencies {
            classpath 'org.apache.commons:commons-lang3:3.4'
        }
    }


    task test << {
        println org.apache.commons.lang3.StringEscapeUtils.escapeXml10('no matter')
    }
}

The output:

* What went wrong:
Execution failed for task ':submodule:test'.
> No signature of method: static org.apache.commons.lang3.StringEscapeUtils.escapeXml10() is applicable for argument types: (java.lang.String) values: [no matter]
  Possible solutions: escapeXml(java.lang.String), escapeHtml3(java.lang.String), escapeHtml4(java.lang.String), unescapeXml(java.lang.String), escapeCsv(java.lang.String), escapeJava(java.lang.String)

this is because gradle uses commons-lang3 of version 3.1 where method esca[eXml10() is missing.

2

There are a few things going on here that confuse things. But the most important is that there is a separate classpath configuration for the root project and each subproject, and these are resolved separately and loaded into separate ClassLoaders. The ClassLoader for the root project is the parent of the ClassLoader for a subproject, and Java by default will resolve from the parent in preference to the child.

3

Ok, but anyway something is wrong here.
In the end our resolved dependencies don’t match actual classpath.

Why not to throw an exception if some dependency is not “resolvable”?

4

reproduced on Gradle 3.0