square / square/square-java-sdk
Maven builds get an empty okhttp jar
Dieses Issue hat noch niemand übernommen.
- Vorherrschende Sprache
- Java
- Sterne
- 70
- Forks
- 37
- Ø Merge
- 2 Std. 7 Min.
- Gemergte PRs (30 T.)
- 1
Beschreibung
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.
Beitragsleitfaden
Für dieses Repository ist kein Beitragsleitfaden indexiert
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Rechercherichtung
Reproduziere den Fehler mit der Maven-Abhängigkeitsdeklaration aus dem Issue und untersuche das veröffentlichte POM sowie seine transitiven Abhängigkeiten. Verwende den Stacktrace von ClientOptions.builder als Einstiegspunkt; abgeschlossen ist die Aufgabe, wenn Maven-Verbraucher okhttp-jvm transitiv erhalten und nicht mehr auf ClassNotFoundException für okhttp3.Interceptor stoßen.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- java, kotlin
- Bereich
- build-system
- Issue-Typ
- Bug
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Aktivitätsstatus
- Ruhig
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 68/100