You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An old transiently dependent module that was "masked" by a new module, is still listed in the runtime configurations.
I added a task that copies the dependencies (i.e. copyRuntimeLibs) to build/runtimeLibs.
Expected Behavior
Old module which is "replaced" by the newer version module should not be included build/runtimeLibs.
Current Behavior
Both the old module and the module are found in build/runtimeLibs.
Context
I discovered this when I upgraded our build from Gradle 1.11 to Gradle 3.4.1. Suddenly our task that would create a distribution zip included org.apache.commons:commons-io:1.3.2 in addition to commons-io:commons-io:2.4.
This caused tests to fail since the JVM loaded the old module instead of the new...
Steps to Reproduce (for bugs)
Here's a build.gradle that reproduces the problem pretty clearly:
plugins {
id 'com.gradle.build-scan' version '1.6'
}
buildScan {
licenseAgreementUrl ='https://gradle.com/terms-of-service'
licenseAgree ='yes'
}
apply plugin: 'java'/** * This explicit resolution strategy block is required in Gradle 3.4.1 to avoid including * org.apache.commons:commons-io:1.3.2 in the list of depenencies. * Gradle 1.11 handles this without this block *configurations.all { resolutionStrategy.eachDependency { DependencyResolveDetails details -> if (details.requested.group == 'org.apache.commons' && details.requested.name == 'commons-io') { details.useTarget group: 'commons-io', name: 'commons-io', version: '2.4' } }}*/repositories {
jcenter()
}
task wrapper(type: Wrapper) {
gradleVersion ='3.4.1'
}
dependencies {
//jmxterm has a transient depenendcy on 'org.apache.commons:commons-io:1.3.2'
compile 'org.cyclopsgroup:jmxterm:1.0-alpha-4'//should conflict with 'org.apache.commons:commons-io:1.3.2' and override it
compile 'commons-io:commons-io:2.4'
}
task copyRuntimeLibs(type: Copy) {
into "build/runtimeLibs"
from configurations.runtime
doFirst() {
print'Contents of build/runtimeLibs before copy: 'printlnnewFile('build/runtimeLibs').listFiles()
}
doLast{
print'Contents of build/runtimeLibs after copy: 'printlnnewFile('build/runtimeLibs').listFiles()
}
}
task printConfigurationLibs() {
doLast() {
configurations.each { config->println"$config"
config.allDependencies.each { println"$it" }
println''
}
}
}
bmuschko
changed the title
Conflict Resolution broken when module group changes
Module resolution does not evaluate POM relocation statement
Aug 24, 2017
An old transiently dependent module that was "masked" by a new module, is still listed in the runtime configurations.
I added a task that copies the dependencies (i.e.
copyRuntimeLibs
) to build/runtimeLibs.Expected Behavior
Old module which is "replaced" by the newer version module should not be included build/runtimeLibs.
Current Behavior
Both the old module and the module are found in build/runtimeLibs.
Context
I discovered this when I upgraded our build from Gradle 1.11 to Gradle 3.4.1. Suddenly our task that would create a distribution zip included org.apache.commons:commons-io:1.3.2 in addition to commons-io:commons-io:2.4.
This caused tests to fail since the JVM loaded the old module instead of the new...
Steps to Reproduce (for bugs)
Here's a build.gradle that reproduces the problem pretty clearly:
Your Environment
Reproduced on Ubuntu 14.0.4 with Java 7u121 jdk.
https://scans.gradle.com/s/rqt2v6zcecwh6
The text was updated successfully, but these errors were encountered: