'Gradle: Override transitive dependency by version classifier

One of the dependencies declared in my project has a transitive dependency on 'com.google.guava:guava:15.0'. But my application deployed on WAS/Weblogic doesn't work due to a CDI issue which has been fixed in 'com.google.guava:guava:15.0:cdi1.0'. (same version, but with classifier) I need to tell gradle to use this jar during build and packaging. I am trying to figure on how we can ovrride this transitive dependency with a jar specific version classifier.

Tried the following approches:

  1. Added the dependency explicitly: compile 'com.google.guava:guava:15.0:cdi1.0'. But both jars got included in the resultant WAR.

  2. Added the dependency explicitly and defined a resolution strategy:

    configurations.all {
    resolutionStrategy {
        force 'com.google.guava:guava:15.0:cdi1.0'
    }
}

    Even this didn't work.

  3. Defined a resolution strategy to check and change the version.

    configurations.all {
     resolutionStrategy.eachDependency { DependencyResolveDetails details ->
         if (details.requested.group + ":" + details.requested.name == 'com.google.guava:guava') {
            details.useVersion "15.0:cdi1.0"
            //details.useTarget "com.google.guava:guava:15.0:cdi1.0"
        }
    }
}

    Even this didn't work.

Need your suggestions on how this issue can be tackled.

javamavengradleguavadependency-management


Solution 1:[1]

Currently classifiers are not yet taken into account when it comes to resolutionStrategies. A workaround for you might excluding the transitive Guava library when declaring your dependencies and adding the Guava cdi1.0 version explicitly:

dependencies {
    compile ("org.acme:someDependency:1.0"){
        exclude group: 'com.google.guava', module: 'guava'
    }       
    compile "com.google.guava:guava:15.0:cdi1.0"
}

Solution 2:[2]

I came across a more elegant approach which is simply:

compile ("com.google.guava:guava:15.0:cdi1.0") {
  force = true
}

Explanation

Setting force = true for a dependency tells gradle to use the specified version in case of a version conflict

Solution 3:[3]

Gradle 4.5.1 has the function DependencySubstitutions. Here an example to replace a dependency:

configurations.each {
    c -> c.resolutionStrategy.dependencySubstitution {
        all { DependencySubstitution dependency ->
            if (dependency.requested.group == 'org.json') {
                dependency.useTarget 'com.vaadin.external.google:android-json:0.0.20131108.vaadin1'
            }
        }
    }
}

Solution 4:[4]

implementation( group: 'commons-codec', name: 'commons-codec'){
      version{
        strictly "[1.15]"
      }
   }

This works for me with gradle 6.6.1

The documentation link for strictly can found here https://docs.gradle.org/current/userguide/rich_versions.html#rich-version-constraints

Solution 5:[5]

This will not work if the same dependency is pointed by some other jar. Sureshot way to exclude the dependency

configurations {
 all*.exclude group: 'com.google.guava', module:'guava-jdk5'
}

Solution 6:[6]

Since force = true is deprecated, relevant solution is to use strictly(...) version, e.g.:

dependencies {
    // no need to exclude transitive spring-data-relational from this dependency
    implementation("org.springframework.data", "spring-data-r2dbc", "1.1.0.RC1")

    implementation("org.springframework.data", "spring-data-relational").version {
        strictly("2.0.0.RC1")
    }
}

P.S. tested on Gradle 6.3

Solution 7:[7]

Try this:

configurations.all {
    resolutionStrategy.eachDependency { DependencyResolveDetails details ->

        // https://docs.gradle.org/current/userguide/resolution_rules.html
        if (details.requested.group == 'com.google.guava' && details.requested.name == 'guava') {
            details.useVersion '15.0:cdi1.0'
        }
    }
}

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 informatik01
Solution 2
Solution 3
Solution 4 Pravanjan
Solution 5 Abhijit Mazumder
Solution 6 uptoyou
Solution 7 logbasex

Related Questions