I've got what I think is a pretty simple setup. I ...

# squarelibraries

[Colton Idle]

I've got what I think is a pretty simple setup. I have an androidlibrary module... and a small app module to exercise said library.

okhttp is only added to the androidlibrary module. ./gradlew androidlibrary:assemble is successful, but ./gradlew app:assemble fails due to

* What went wrong:
Execution failed for task ':app:checkDebugDuplicateClasses'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.CheckDuplicatesRunnable
   > Duplicate class okhttp3.Address found in modules okhttp-jvm-5.1.0.jar -> okhttp-jvm-5.1.0 (com.squareup.okhttp3:okhttp-jvm:5.1.0) and okhttp-release.aar -> okhttp-release-runtime (com.squareup.okhttp3:okhttp-android:5.1.0)

seems like something regarding okhttp-jvm and okhttp-android? according to docs, this shouldn't be an issue since im using gradle and not maven?

[Colton Idle]

In terms of deps, the only things I'm bringing in explicitly is okhttp and okio in the library. i thought maybe switching the implementation to api would do the trick, but no go. im still a library noob so maybe im making some beginner mistake here.

AI is going wild and writing gradle tasks to rewrite all of okhttp-jvm to okhttp-android.

[ephemient]

figure out why you have okhttp-jvm in the app classpath at all

./gradlew :app:dependencyInsight --configuration debugRuntimeClasspath --dependency com.squareup.okhttp3:okhttp-jvm

[Colton Idle]

Hmmm... https://github.com/open-telemetry/opentelemetry-android is the culprit apparently

[Colton Idle]

im using the android-bom, but i guess it uses okhttp-java. hrm. i guess a bug on their end

[Colton Idle]

hm. their own repo has this

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

so maybe i should also dump that into my app
https://github.com/open-telemetry/opentelemetry-android/blob/1f6c876e04c368f22294c0756ea00cf36bf42ef5/demo-app/build.gradle.kts#L101

[ephemient]

https://github.com/open-telemetry/opentelemetry-android/issues/1294

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

[Colton Idle]

nice. okay. not just me. I wonder if since im making a library here if I should call out that all consumers of my library should add the

configurations.all {
    resolutionStrategy {
        eachDependency {
...

themselves in the app module OR if this is something I can do in the library so that app devs don't have to think about it.

[Colton Idle]

alright. i found another issue.

noob question but. in my library im using libA and libB, libA pulls in okhttp 5.x and libB pulls in okhttp 4.x.

can i not use those two libraries together i guess? i just get the dupe class error again.

[ephemient]

they are binary compatible, and Gradle should pick just the higher version

[ephemient]

the move to 5.x does have some source incompatibilities though

[Colton Idle]

ah. indeed gradle just picked the higher version. how does one know that 4 and 5 are binary compatible. i looked in the rel notes and it didn't seem to say anything regarding it.

[ephemient]

okhttp has been using japicmp since before 4.x release and kotlin bcv since before 5.x release

[Colton Idle]

going to mark this as completed. thanks for teaching (as always) ephemient.

long term, i would love to know if the okhttp maintainers think theres a better way for openetelemetry-android and openetelemetry-java to expose/consume okhttp.

also TIL that okhttp now requires initialization in my Application class. gotta dig into that!

[ephemient]

it integrates with androidx.startup so it shouldn't require any setup unless you've disabled that

[Colton Idle]

yeah. i typically disable all androidx.startup stuff. i dont think okhttp required that in the past, which is why ive gotta look into what changed in 5 vs 4