Develop Reference

How to resolve gradle dependency conflicts on library root dependency?

In my project I have two dependencies with okio as a transitive dependency conflict. In theory, gradle should solve it by choosing the highest version, but that didn't work.
I have been trying everything, since exclude until force the version from okio lib, but nothing works. Looking on external libraries path, I realized that one of the dependencies contains the okio as a path of the dependency, and I believe that this is the problem. But how can I solve this?
This is a simple gradle example with my two dependencies. Commented lines are my failed attempts to solve the problem:
plugins {
id 'org.jetbrains.kotlin.jvm' version '1.3.72'
}
repositories {
mavenCentral()
}
//configurations.all {
// resolutionStrategy.force('com.squareup.okio:okio:2.4.3')
//}
dependencies {
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8"
// -> dependency one
implementation "com.squareup.retrofit2:retrofit:2.7.2"
// implementation ("com.squareup.retrofit2:retrofit:2.7.2"){
// exclude group: 'com.squareup.okio'
// }
// -> dependency two
implementation "com.eternitywall:java-opentimestamps:1.18"
// implementation ("com.eternitywall:java-opentimestamps:1.18") {
// exclude group: 'com.squareup.okio'
// }
// implementation "com.squareup.okio:okio:2.4.3"
// implementation "com.squareup.okio:okio"
// constraints {
// implementation("com.squareup.okio:okio:2.4.3") {
// because 'transitive version conflict'
// }
// }
}
To get the error, just have a Main.kt file with the code:
import okhttp3.OkHttpClient
fun main(args: Array<String>) {
OkHttpClient.Builder()
}
And the error obtained is:
Exception in thread "main" java.lang.NoSuchMethodError: 'boolean okio.ByteString.startsWith(okio.ByteString)'
at okio.Options.of(Options.java:64)
at okhttp3.internal.Util.<clinit>(Util.java:73)
at okhttp3.OkHttpClient.<clinit>(OkHttpClient.java:124)
at okhttp3.OkHttpClient$Builder.<init>(OkHttpClient.java:449)
at MainKt.main(Main.kt:4)
And finally, this is the library root that I mentioned from dependence with the included okio
I will be very grateful if you can help me.
Thanks in advance!!

Well, it seems that the only solution is to separate the app into modules, placing each dependency in a different module. Even though I was reluctant it was the only way I found.

Gradle build ignores Jetbrains annotations

Let's say we have the following test code:
import org.jetbrains.annotations.NotNull;
import org.junit.Test;
public class NullTest {
#Test
public void testNull() {
doNothing(null);
}
private #NotNull String doNothing(#NotNull String value) {
return value;
}
}
The test will pass when running gradle test directly or if IDEA delegates the action to gradle.
But it will fail with IllegalArgumentException: Argument for #NotNull parameter 'value' must not be null exception if it runs using IDEA runner (not delegated to gradle).
The question is: how to fail the test running it with gradle?

The easiest solution I have found is to apply org.jetbrains.intellij plugin.
Because among other things this plugin "patches compile tasks to instrument code with nullability assertions".
apply plugin: 'org.jetbrains.intellij'
intellij {
instrumentCode = true
downloadSources = false
}

Try adding the following to your dependencies. It worked for me.
compile 'org.jetbrains:annotations:13.0'

With this code - no way, because you use annotations from org.jetbrains.annotations.*, that use only in intellij idea tests runner. For gradle, annotation #NotNull (or #Nullable) says nothing. Maven also doesn't see this annotation. I can advise you use Objects.requireNonNull(T obj) for null checking.

We found that Lombok's #NonNull works better. But you need to configure IDEA to prefer this one during nullability-related analysis and generation

Adding the following dependency worked for me:
compile group: 'org.jetbrains', name: 'annotations', version: '15.0'
Run the 'dependencies' task & push the refresh button in Gradle.

Writing custom Lombok Annotation handlers

I want to write custom Lombok Annotation handlers. I know http://notatube.blogspot.de/2010/12/project-lombok-creating-custom.html. But the current lombok jar file does not contain many .class files, but files named .SCL.lombok instead.
I found, the .SCL.lombok files are the .class files, the build script of Lombok does rename them while generating the jar file, and the ShadowClassLoader is capable of loading these classes -- and the acronym SCL seems to come from this. It seems the reason for this is just to "Avoid contaminating the namespace of any project using an SCL-based jar. Autocompleters in IDEs will NOT suggest anything other than actual public API."
I was only able to compile my custom handler by
unpacking the contents of the lombok.jar
renaming the .SCL.lombok files to .class
adding the resulting directory to the compile classpath
In addition, to be able to use my custom handler, I needed to create a new fat jar containing both the lombok classes and my custom handler. The custom lombok class loader essentially prevents adding custom handlers in other multiple jars.
Is this the only way to extend Lombok? Or am I missing something?
I am using the following buildscript
apply plugin: 'java'
repositories {
jcenter()
}
configurations {
lombok
compileOnly
}
def unpackedAndRenamedLombokDir = file("$buildDir/lombok")
task unpackAndRenameLombok {
inputs.files configurations.lombok
outputs.dir unpackedAndRenamedLombokDir
doFirst {
mkdir unpackedAndRenamedLombokDir
delete unpackedAndRenamedLombokDir.listFiles()
}
doLast {
copy {
from zipTree(configurations.lombok.singleFile)
into unpackedAndRenamedLombokDir
rename "(.*)[.]SCL[.]lombok", '$1.class'
}
}
}
sourceSets {
main {
compileClasspath += configurations.compileOnly
output.dir(unpackedAndRenamedLombokDir, builtBy: unpackAndRenameLombok)
}
}
tasks.compileJava {
dependsOn unpackAndRenameLombok
}
dependencies {
compile files("${System.properties['java.home']}/../lib/tools.jar")
compile "org.eclipse.jdt:org.eclipse.jdt.core:3.10.0"
compile 'javax.inject:javax.inject:1'
lombok 'org.projectlombok:lombok:1.16.6'
compileOnly files(unpackedAndRenamedLombokDir)
}

In the meantime Reinier Zwitserloot created a new git-branch sclExpansionUpdate, that contains an updated version of the ShadowClassLoader:
ShadowClassLoader is now friendlier to trying to extend lombok.
Your (separate) jar/dir should have a file named
META-INF/ShadowClassLoader. This file should contain the string
'lombok'. If you have that, any classes in that jar/dir will be loaded
in the same space as lombok classes. You can also rename the class
files to .SCL.lombok to avoid other loaders from finding them.
I guess this did not yet make it into the main branch because it certainly has not been tested that much - I just tried it out for myself and it contains a little bug that prevents loading the required META-INF/services from extensions. To fix it you should replace two method calls to partOfShadow with inOwnBase:
[... line 443]
Enumeration<URL> sec = super.getResources(name);
while (sec.hasMoreElements()) {
URL item = sec.nextElement();
if (!inOwnBase(item, name)) vector.add(item); // <<-- HERE
}
if (altName != null) {
Enumeration<URL> tern = super.getResources(altName);
while (tern.hasMoreElements()) {
URL item = tern.nextElement();
if (!inOwnBase(item, altName)) vector.add(item); // <<-- AND HERE
}
}
I tested it with the above fix and it seems to work fine (not tested much though).
On a side note: with this new extension mechanism, it is now finally also possible to have the extensions annotation handlers and annotations in a different namespace than "lombok" - nice!

Using the input from this question and from the other answer (by Balder), we managed to put together a custom Lombok annotation handler: Symbok. Feel free to use that as a sample for writing your own.
BTW, instead of writing a custom Lombok handler, you could also implement a javac plugin instead -- it might be simpler.

How to shade a transitive dependency in Gradle?

Is there a way to shadow a particular (transitive) dependency in Gradle? My situation: I have a project that depends directly on com.amazonaws:aws-java-sdk-emr:1.10.33 and org.apache.hadoop:hadoop-aws:2.7.1, but hadoop-aws in turns depends on com.amazonaws:aws-java-sdk-emr:1.7.4 which screws the final JAR, but I need both anyway.
Is it currently possible to do something like this?
shadowJar {
relocate('com.amazonaws', 'shadowedstuff.awsjdk') {
include(dependency('com.amazonaws:aws-java-sdk:1.7.4'))
}
}
Or a not-so-dirty workaround for it?
Thanks!
NOTE: shading the aws-sdk which my projects depends on directly is not an option. This is a simplification and in the original setup some reflection is going on.

Yes, you can use the shadow plugin for Gradle to which has a very similar syntax to your example:
// Configuring Filtering for Relocation
shadowJar {
relocate('junit.textui', 'a') {
exclude 'junit.textui.TestRunner'
}
relocate('junit.framework', 'b') {
include 'junit.framework.Test*'
}
}

Apologies if I've misunderstood your situation and it is in fact more complex but it looks like the exclusion can just be provided in the dependency declaration?
dependencies {
...
compile('org.apache.hadoop:hadoop-aws:2.7.1') {
exclude group: 'com.amazonaws', module: 'aws-java-sdk'
}
...
}

You can try the resolutionStrategy (https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html) to force a particular version.
Example from a projet:
configurations {
testImplementation.extendsFrom compileOnly
all {
resolutionStrategy {
// Force jackson 2.4.4 for Spark
force 'com.fasterxml.jackson.core:jackson-core:2.4.4', 'com.fasterxml.jackson.core:jackson-databind:2.4.4', 'com.fasterxml.jackson.core:jackson-annotations:2.4.4'
force 'com.google.guava:guava:23.6-jre'
}
}
}

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 out how we can override this transitive dependency with a jar specific version classifier.
Tried the following approaches:
Added the dependency explicitly: compile 'com.google.guava:guava:15.0:cdi1.0'. But both jars got included in the resultant WAR.
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.
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.

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"
}

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

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

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'
}
}
}
}

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'
}

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

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'
}
}
}

try this its working perfectly in my case in App level in build.gradle file
android {
configurations {
all*.exclude module: 'conceal'
all*.exclude module: 'bcprov-jdk15on'
}
}