Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Module resolution does not evaluate POM relocation statement #1789

Closed
idanavisar opened this issue Apr 9, 2017 · 2 comments
Closed

Module resolution does not evaluate POM relocation statement #1789

idanavisar opened this issue Apr 9, 2017 · 2 comments
Assignees
Milestone

Comments

@idanavisar
Copy link

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: '
    	println new File('build/runtimeLibs').listFiles()
    }
    doLast{
	print 'Contents of build/runtimeLibs after copy: '
	println new File('build/runtimeLibs').listFiles()
    }
}

task printConfigurationLibs() {
  doLast() {
    configurations.each { config ->
      println "$config"
      config.allDependencies.each { println "  $it" }
      println ''
    }
  }
}

Your Environment

Reproduced on Ubuntu 14.0.4 with Java 7u121 jdk.

@idanavisar
Copy link
Author

idanavisar commented Apr 9, 2017

Note that running gradlew dependcyInsight indicates that Gradle performs the conflict resolution properly...

See here:
https://scans.gradle.com/s/p76c7gfx4qgka

blindpirate added a commit to blindpirate/gradle that referenced this issue Aug 13, 2017
@bmuschko bmuschko changed the title Conflict Resolution broken when module group changes Module resolution does not evaluate POM relocation statement Aug 24, 2017
@bmuschko bmuschko added this to the 4.2 RC1 milestone Aug 28, 2017
@bmuschko
Copy link
Contributor

@idanavisar You should be able to try this out with a nightly of Gradle. We'd love to hear if it fixes your issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants