[KOTLIN] Declare public-API HTTP/JSON/date dependencies as api in the Gradle template
Fixes #25576
What
kotlin-client/build.gradle.mustache declares the HTTP, JSON and date libraries as implementation although their types are part of the generated client's public API. With Gradle's java-library rules, implementation dependencies do not land on a consumer's compile classpath, so any consumer code that touches generated Api members fails to compile with Cannot access class ... Check your module classpath for missing or conflicting dependencies.
This PR switches exactly those dependencies to api:
| dependency | where its types leak into the public API |
|---|---|
okhttp (jvm-okhttp4) | ApiClient.defaultClient: OkHttpClient, every Api(basePath, client: Call.Factory, ...) |
retrofit (jvm-retrofit2) | generated Api methods return retrofit2.Call |
rxjava (jvm-retrofit2 + useRxJava3) | generated Api methods return io.reactivex.rxjava3.core.Single |
| oltu oauth2 client (jvm-retrofit2) | ApiClient.getTokenEndPoint(): OAuthClientRequest.TokenRequestBuilder? |
moshi-kotlin / moshi (+ moshi-adapters) | Serializer.moshi: Moshi, Serializer.moshiBuilder: Moshi.Builder |
gson | Serializer.gson: Gson, Serializer.gsonBuilder: GsonBuilder |
jackson-module-kotlin (Jackson 2 and 3) | Serializer.jacksonObjectMapper: ObjectMapper / JsonMapper |
kotlinx-serialization-json | Serializer.kotlinxSerializationJson: Json |
threetenbp | model properties typed org.threeten.bp.OffsetDateTime etc. |
kotlinx-datetime | model properties typed kotlinx.datetime.LocalDate/LocalTime for format: date/time schemas, plus the public LocalDateAdapter/LocalTimeAdapter signatures |
ktor-client-core (jvm-ktor) | Api constructors take HttpClientEngine/HttpClientConfig |
vertx-core (jvm-vertx) | Api constructors take Vertx, methods return Future |
spring-boot-starter-webflux (jvm-spring-webclient) | Api methods return Mono (reactor-core is pulled in transitively by the starter) |
spring-boot-starter-web (jvm-spring-restclient) | Serializer.jacksonObjectMapper (jackson comes in transitively with the starter) |
Everything whose types only appear inside generated method bodies stays implementation: logging-interceptor, the retrofit converter-* artifacts and adapter-rxjava3, jackson-datatype-jsr310 (module registration only), the non-core Ktor modules (content-negotiation, serialization), vertx-web-client/vertx-lang-kotlin/vertx-uri-template (the generated code creates the WebClient internally), kotlinx-coroutines-core, kotlin-reflect and reactor-core. The deprecated jvm-volley is left untouched; its public GsonRequest extends com.android.volley.Request, so it would deserve the same treatment, but as noted in the issue this could not be verified without the Android SDK.
One addition beyond the list in the issue: kotlinx-datetime. With dateLibrary=kotlinx-datetime the generated models expose kotlinx.datetime types in property signatures (and the generated LocalDateAdapter/LocalTimeAdapter reference them in public method signatures unconditionally) — the same class of leak as threetenbp, which is already in the list; it was simply not covered by the issue's table.
Why api and not an option flag
The java-library rule is mechanical: a dependency whose types appear in the public API of the shipped artifact belongs in api. There is nothing to opt into — the generated code puts these types into signatures unconditionally, so the only consumer-side workaround today is redeclaring the client's own dependencies by hand. The same template family already does this where types leak: the multiplatform template declares Ktor as api (#9755), and the jvm-microprofile template declares Mutiny as api (#25374). This PR applies the same semantics to the JVM libraries.
Verification
./mvnw -pl modules/openapi-generator test: 5755 tests, 0 failures, 0 errors, 18 skipped.- Regenerated all 69 kotlin client sample configs (
bin/configs/kotlin*.yamlwithgeneratorName: kotlin). 59 generatedbuild.gradlefiles change (dependency declarations only); the 9 multiplatform samples usebuild.gradle.ktsand are untouched. ./gradlew compileKotlinpasses on the regeneratedkotlin(default jvm-okhttp4),kotlin-jvm-okhttp4-coroutines,kotlin-retrofit2andkotlin-kotlinx-datetimesamples (Gradle 8.14.5, JDK 21).- Consumer compile check (manual — the repo has no CI pattern for consumers): a Gradle 8.14.5 consumer project with
includeBuild(...)on the generated client and the reproducer source from the issue:- against the pre-fix client it fails with
e: Cannot access class 'okhttp3.OkHttpClient',e: Cannot access class 'okhttp3.Call.Factory'ande: Cannot access class 'com.squareup.moshi.Moshi'— the exact errors from the issue; - against the regenerated client it compiles. A second consumer calling
ApiClient().createService(PetApi::class.java).getPetById(1L).execute()andApiClient().getTokenEndPoint()?.setClientId("x")against the regeneratedkotlin-retrofit2client compiles as well.
- against the pre-fix client it fails with
Summary by cubic
Fixes consumer compilation failures with generated Kotlin clients by declaring HTTP, JSON, and date libraries whose types appear in the generated public API as api instead of implementation (issue #25576).
Bug Fixes
- OkHttp, Retrofit, RxJava3, the Oltu OAuth client, Moshi, Gson, Jackson, kotlinx-serialization, Ktor core, Vert.x core, the Spring starters, threetenbp, and kotlinx-datetime now reach consumer compile classpaths.
- Dependencies used only inside method bodies, such as logging-interceptor and the Retrofit converters, stay as
implementation. kotlinx-datetimewas added beyond the issue's table because generated model properties and date adapters expose its types in public signatures.- 59 sample
build.gradlefiles were regenerated; multiplatform samples are untouched.