Maven builds get an empty okhttp jar

Using

<dependency>
    <groupId>com.squareup</groupId>
    <artifactId>square</artifactId>
    <version>47.0.1.20260715</version>
    <scope>compile</scope>
</dependency>

The resulting jar gets an empty okhttp jar. We now need to add

<dependency>
    <groupId>com.squareup.okhttp3</groupId>
    <artifactId>okhttp-jvm</artifactId>
    <version>5.2.1</version>
</dependency>

for the build to work.

Some additional detail on the failure and root cause:

Symptom — any Maven-built app using SDK 47.x fails at runtime the first time a client is built:

  java.lang.ClassNotFoundException: okhttp3.Interceptor
      at com.squareup.square.core.ClientOptions.builder(ClientOptions.java:102)
      at com.squareup.square.SquareClientBuilder.buildClientOptions(SquareClientBuilder.java:104)
      at com.squareup.square.SquareClientBuilder.build(SquareClientBuilder.java:255)

Root cause — the SDK depends on com.squareup.okhttp3:okhttp 5.x, which is published as a Kotlin Multiplatform artifact. The root okhttp jar on Maven Central contains no classes (just META-INF/kotlin-project-structure-metadata.json); the real JVM classes live in okhttp-jvm.
Gradle resolves the redirect via Gradle Module Metadata, but Maven ignores .module files, so Maven consumers silently get the empty jar.
Per the OkHttp README (https://github.com/square/okhttp#requirements), "Maven projects must select between okhttp-jvm and okhttp-android" — see also square/okhttp#8913.

Suggested fix — declare com.squareup.okhttp3:okhttp-jvm in the SDK's published POM so the correct artifact flows transitively to Maven consumers. This is how OpenTelemetry resolved the identical breakage (open-telemetry/opentelemetry-java#7491), and it matches what okio itself does: okio's root POM declares okio-jvm as a plain compile dependency, which is why okio classes resolve fine under Maven while okhttp's don't.

Reproduisez l’échec avec la déclaration de dépendance Maven de l’issue et inspectez le POM publié ainsi que ses dépendances transitives. Utilisez la trace de la pile de ClientOptions.builder comme point d’entrée ; c’est terminé lorsque les consommateurs Maven reçoivent okhttp-jvm de manière transitive et ne rencontrent plus de ClassNotFoundException pour okhttp3.Interceptor.