OkHttp jvm android resolution seems to be back

[VitaSokolova]

Hi!

I have an Android project with parts of KMP code. We use Ktor to create our HttpClient. I use io.opentelemetry.android:android-agent, but I'm missing http calls details in my logs. I thought I would use io.opentelemetry.android.instrumentation:okhttp3-agent like described here, but if I add these dependencies

plugins { 
    id("net.bytebuddy.byte-buddy-gradle-plugin") version "1.17.7"
}
...
dependencies {
    api(platform("io.opentelemetry.android:opentelemetry-android-bom:0.15.0-alpha"))
    implementation("io.opentelemetry.android:android-agent")

    implementation("io.opentelemetry.android.instrumentation:okhttp3-library:0.15.0-alpha")
    byteBuddy("io.opentelemetry.android.instrumentation:okhttp3-agent:0.15.0-alpha")
}

I run into the OkHttp jvm android resolution issue again in version 0.15.0:

Duplicate class okhttp3.Address found in modules okhttp-4.12.0.jar -> okhttp-4.12.0 (com.squareup.okhttp3:okhttp:4.12.0) and okhttp-jvm-5.1.0.jar -> okhttp-jvm-5.1.0 (com.squareup.okhttp3:okhttp-jvm:5.1.0)
...

I saw that being fixed in 0.14.0 in this PR from @LikeTheSalad , but it's still an issue for me.

[LikeTheSalad]

Hi @VitaSokolova

TL;DR: My PR helped fix OTel Android's compilation; however, it won't fix this issue for consumers of OTel Android, unfortunately.

To fix it, you'd need to ask Gradle to choose okhttp over okhttp-jvm within your Android app's build.gradle.kts file, similarly to how it's done for our demo app, like so:

configurations.all {
    resolutionStrategy {
        eachDependency {
            if (requested.group == "com.squareup.okhttp3" && requested.name == "okhttp-jvm") {
                useTarget("com.squareup.okhttp3:okhttp:${requested.version}")
                because("choosing okhttp over okhttp-jvm")
            }
        }
    }
}

---

The more detailed answer is that, on version 5.x, OkHttp split itself into 2 artifact flavors, one for Android and another for plain Java projects, and they relied on Gradle to tell which flavor is needed automatically so that from the old okhttp's coordinates (com.squareup.okhttp3:okhttp) Gradle would redirect to the specific coordinates depending on the project, i.e. com.squareup.okhttp3:okhttp-android or com.squareup.okhttp3:okhttp-jvm for Android or plain Java projects, respectively.

This works well when compiling JVM projects using Gradle; however, it caused issues for other compilation tools such as Maven. Because of this, to avoid breaking plain Java projects, OTel Java switched to explicitly defining okhttp-jvm as their dependency for OkHttp (which I think makes sense, given that they are focused primarily on plain Java projects), and since OTel Android depends on OTel Java as its base, it means that we get okhttp-jvm as a transitive dependency. My PR helped to avoid it for OTel Android's compilation, but since OTel Android uses OTel Java's dependencies, which in turn use okhttp-jvm, it means that OTel Android's consumer projects, such as yours, will get OTel Java's transitive okhttp-jvm dependency, which clashes with the one used by your Android project. This is fixable using the same Gradle config I applied to OTel Android that I mentioned above.

This is something we've recently discussed in the Android SIG meeting, where we decided to propose creating an Android-specific artifact within OTel Java, where the OkHttp Android flavor is used instead of the Java one. This would allow OTel Android to declare that new module as dependency, which would prevent the transitive okhttp-jvm one from leaking into OTel Android's consumer projects.

[VitaSokolova]

Hi! Thank you for the quick response, that was actually the first thing I tried before opening the issue. But I have a multimodel project and I declared it is core build.gradle.kts, that was a mistake, I needed app's module build.gradle.kts

[breedx-splk]

Circling back after discussing today in the java sig meeting -- it looks like open-telemetry/opentelemetry-java#7681 is intended to address this, but it hasn't been released yet. Once it does, the maven pom file may still contain the -jvm flavor, but the gradle module will publish the unspecified suffix, which will, on android, resolve to the -android flavor. 🤞🏻

[ColtonIdle]

Looks like the https://github.com/open-telemetry/opentelemetry-java/releases/tag/v1.55.0 release fixes this. I guess we need a new release of opentelemetry-android?

[breedx-splk]

Yup, should happen early next week.