[KOTLIN] Declare public-API HTTP/JSON/date dependencies as api in the Gradle template by Inf1mum · Pull Request #25665 · OpenAPITools/openapi-generator

Inf1mum · 2026-11-13T21:13:02Z

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*.yaml with generatorName: kotlin). 59 generated build.gradle files change (dependency declarations only); the 9 multiplatform samples use build.gradle.kts and are untouched.
./gradlew compileKotlin passes on the regenerated kotlin (default jvm-okhttp4), kotlin-jvm-okhttp4-coroutines, kotlin-retrofit2 and kotlin-kotlinx-datetime samples (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' and e: 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() and ApiClient().getTokenEndPoint()?.setClientId("x") against the regenerated kotlin-retrofit2 client compiles as well.

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-datetime was added beyond the issue's table because generated model properties and date adapters expose its types in public signatures.
59 sample build.gradle files were regenerated; multiplatform samples are untouched.

^{Written for commit 49afde9. Summary will update on new commits.}

… api What: in kotlin-client's build.gradle.mustache, declare the libraries whose types appear in the generated client's public API as `api` instead of `implementation`: moshi-kotlin and moshi-adapters (moshi), moshi (moshiCodeGen), gson, jackson-module-kotlin (Jackson 2 and 3), kotlinx-serialization-json, kotlinx-datetime, threetenbp, okhttp (jvm-okhttp4), spring-boot-starter-webflux and spring-boot-starter-web (jvm-spring-webclient / jvm-spring-restclient), the oltu oauth2 client, rxjava3 and retrofit (jvm-retrofit2) and vertx-core (jvm-vertx). Kotlin client samples regenerated accordingly (build.gradle only). Why: those types are part of the generated client's public API, so with `implementation` a Gradle consumer of the published client cannot compile code that touches generated members (OpenAPITools#25576): ApiClient.defaultClient is an OkHttpClient and every Api takes a Call.Factory (jvm-okhttp4); generated Api methods return retrofit2.Call or rxjava3.Single and getTokenEndPoint() returns an oltu TokenRequestBuilder (jvm-retrofit2); Api constructors take HttpClientEngine/HttpClientConfig (jvm-ktor) or Vertx and return Future (jvm-vertx); Serializer exposes Moshi, Gson, ObjectMapper/JsonMapper and kotlinx.serialization.json.Json as public members; date libraries appear in model property types and in the public date adapters (threetenbp, kotlinx-datetime). Dependencies used only inside generated method bodies (logging-interceptor, retrofit converter-*/adapter-rxjava3, jackson-datatype-jsr310, ktor content-negotiation and serialization modules, vertx-web-client/lang-kotlin/uri-template, kotlinx-coroutines, kotlin-reflect, reactor-core) stay implementation. The multiplatform template already declares Ktor as api (OpenAPITools#9755) and jvm-microprofile declares Mutiny as api (OpenAPITools#25374); this applies the same java-library semantics to the JVM libraries. How: switched exactly the leaking dependency declarations to `api` in the shared template, then regenerated the kotlin client samples (bin/configs/kotlin*.yaml with generatorName: kotlin; multiplatform samples use build.gradle.kts and are untouched).

cubic-dev-ai

21 issues found across 60 files

Prompt for AI agents (unresolved issues)


Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="samples/client/others/kotlin-jvm-okhttp-path-comments/build.gradle">

<violation number="1" location="samples/client/others/kotlin-jvm-okhttp-path-comments/build.gradle:59">
P3: `moshi-adapters` does not appear in any public signature of this client, and this sample's sources never import it. It is only used inside `Serializer`'s builder setup, so it should stay `implementation`. Make the same change in the `kotlin-client/build.gradle.mustache` template, not just in this generated sample.</violation>
</file>

<file name="samples/client/petstore/kotlin-jvm-vertx-gson/build.gradle">

<violation number="1" location="samples/client/petstore/kotlin-jvm-vertx-gson/build.gradle:60">
P2: `vertx-web-client` is still `implementation`, but `ApiClient.handleResponse` is a protected member whose parameter type is `io.vertx.ext.web.client.HttpResponse`. That is the same kind of public-signature leak this PR fixes for vertx-core and gson, so subclassing consumers can still fail without redeclaring the dependency. Change `vertx-web-client` to `api` as well, in this sample and in the `jvm-vertx` block of the template.</violation>
</file>

<file name="samples/client/petstore/kotlin-jackson/build.gradle">

<violation number="1" location="samples/client/petstore/kotlin-jackson/build.gradle:58">
P3: `jackson-module-kotlin` is only used inside the `Serializer` initializer, so it does not appear in any public signature. The public type `ObjectMapper` comes from `jackson-databind`, which consumers get only transitively through this `api` line. Declare `jackson-databind` explicitly as `api` so the exposed JSON type does not depend on a transitive POM scope.</violation>
</file>

<file name="samples/client/petstore/kotlin-jvm-vertx-jackson/build.gradle">

<violation number="1" location="samples/client/petstore/kotlin-jvm-vertx-jackson/build.gradle:62">
P2: `handleResponse` in `ApiClient` exposes `io.vertx.ext.web.client.HttpResponse` in a protected signature, but `vertx-web-client` is still `implementation`. Subclasses that call this method will fail to compile without redeclaring vertx-web-client. Consider changing that line to `api` as well, matching the stated rule for HTTP types in public signatures.</violation>
</file>

<file name="samples/client/petstore/kotlin-moshi-codegen/build.gradle">

<violation number="1" location="samples/client/petstore/kotlin-moshi-codegen/build.gradle:60">
P3: `moshi-adapters` is not in any public signature of this client; it is only used in the builder initialization (`EnumJsonAdapter`), and this sample does not import it at all. Keep it as `implementation` to follow the PR's own rule for body-only dependencies. The same applies to the matching `api` line in `kotlin-client/build.gradle.mustache`.</violation>
</file>

<file name="samples/client/petstore/kotlin-jvm-vertx-moshi/build.gradle">

<violation number="1" location="samples/client/petstore/kotlin-jvm-vertx-moshi/build.gradle:62">
P2: `io.vertx:vertx-web-client` is still `implementation`, but its `HttpResponse` type appears in the protected `handleResponse` signature of the open `ApiClient`. Subclasses of `ApiClient` need that type on the compile classpath, so declare it as `api` like `vertx-core`. Apply the same change in the `jvm-vertx` block of `build.gradle.mustache`.</violation>
</file>

<file name="samples/client/petstore/kotlin-jvm-vertx-jackson-coroutines/build.gradle">

<violation number="1" location="samples/client/petstore/kotlin-jvm-vertx-jackson-coroutines/build.gradle:63">
P2: `vertx-web-client` stays `implementation`, but its `HttpResponse` type appears in the protected `ApiClient.handleResponse` signature. Subclasses of the open `ApiClient` will not compile without redeclaring it, so promote this to `api` too (also in the `kotlin-client/build.gradle.mustache` jvm-vertx block).</violation>
</file>

<file name="samples/client/petstore/kotlin-name-parameter-mappings/build.gradle">

<violation number="1" location="samples/client/petstore/kotlin-name-parameter-mappings/build.gradle:59">
P3: `moshi-adapters` is not referenced in this client's public API, so it should stay `implementation`. Exposing it as `api` adds it to every downstream consumer's compile classpath for no benefit.</violation>
</file>

<file name="samples/client/petstore/kotlin-default-values-jvm-okhttp4/build.gradle">

<violation number="1" location="samples/client/petstore/kotlin-default-values-jvm-okhttp4/build.gradle:59">
P3: `moshi-adapters` is not part of any public signature in the generated client; it is only used inside `Serializer` builder setup. Per this PR's own rule, it should stay `implementation`. Keeping it as `api` leaks an unused artifact onto every consumer's compile classpath.</violation>
</file>

<file name="samples/client/petstore/kotlin-jvm-spring-3-restclient/build.gradle">

<violation number="1" location="samples/client/petstore/kotlin-jvm-spring-3-restclient/build.gradle:65">
P3: `jackson-module-kotlin` is not referenced in any public signature here; it is only called inside the `Serializer` initializer. Keep it `implementation` to match the PR's rule and the neighbouring `jackson-datatype-jsr310` line. Otherwise the module leaks onto consumers' compile classpath without need.</violation>
</file>

<file name="samples/client/echo_api/kotlin-jvm-spring-3-restclient/build.gradle">

<violation number="1" location="samples/client/echo_api/kotlin-jvm-spring-3-restclient/build.gradle:65">
P3: `jackson-module-kotlin` does not need `api` here. Its types appear only in the body of `Serializer`, not in any public signature, so consumers do not need it on their compile classpath. Revert this line to `implementation`, or confirm that the template-wide `api` promotion is intended.</violation>
</file>

<file name="samples/client/petstore/kotlin-array-simple-string-jvm-okhttp4/build.gradle">

<violation number="1" location="samples/client/petstore/kotlin-array-simple-string-jvm-okhttp4/build.gradle:59">
P3: `moshi-adapters` is only used in method bodies (`EnumJsonAdapter.create` in the serializer helper), and this sample does not import it at all. Keep it as `implementation` to follow the PR's rule for body-only dependencies, so downstream consumers do not inherit it on their compile classpath.</violation>
</file>

<file name="samples/client/petstore/kotlin-allOf-discriminator/build.gradle">

<violation number="1" location="samples/client/petstore/kotlin-allOf-discriminator/build.gradle:59">
P3: `moshi-adapters` does not appear in any public signature of this client (it is only imported in `infrastructure/Serializer.kt` and `SerializerHelper.kt`). Keep it as `implementation` to match the PR's rule and avoid leaking an unneeded transitive dependency to consumers.</violation>
</file>

<file name="samples/client/echo_api/kotlin-jvm-spring-3-webclient/build.gradle">

<violation number="1" location="samples/client/echo_api/kotlin-jvm-spring-3-webclient/build.gradle:67">
P3: `Mono` from reactor-core appears in this client's public signatures, but `reactor-core` is still `implementation`. Declare it as `api` too, so the public-API dependency rule is applied consistently and the pinned version reaches consumers.</violation>
</file>

<file name="samples/client/petstore/kotlin-default-values-jvm-retrofit2/build.gradle">

<violation number="1" location="samples/client/petstore/kotlin-default-values-jvm-retrofit2/build.gradle:60">
P3: `moshi-adapters` is only used inside generated initializers and builder code (e.g. `EnumJsonAdapter` in the serializer helpers), not in any public signature. The PR description says such dependencies stay `implementation`. Either switch this to `implementation` (and the template in `kotlin-client/build.gradle.mustache`), or note in the PR why consumers need it on their compile classpath.</violation>
</file>

<file name="modules/openapi-generator/src/main/resources/kotlin-client/build.gradle.mustache">

<violation number="1" location="modules/openapi-generator/src/main/resources/kotlin-client/build.gradle.mustache:160">
P3: `moshi-adapters` is used only by internal serializer implementation, so publishing it as `api` unnecessarily puts it on every consumer's compile classpath. Keep this dependency as `implementation` in both Moshi branches; only Moshi core (via `moshi-kotlin` or `moshi`) is part of the generated public API.</violation>

<violation number="2" location="modules/openapi-generator/src/main/resources/kotlin-client/build.gradle.mustache:200">
P2: The Spring WebClient client exposes `Mono` in public methods, but the direct `reactor-core` dependency remains `implementation`. Declare `reactor-core` as `api` alongside the WebFlux starter so the generated module explicitly publishes every dependency used by its public signatures.</violation>

<violation number="3" location="modules/openapi-generator/src/main/resources/kotlin-client/build.gradle.mustache:238">
P2: `vertx-web-client` is still `implementation`, but its `HttpResponse` type appears in the protected `handleResponse` signature of the public open `ApiClient`. Subclasses of the generated client need it on the compile classpath, so declare it as `api` alongside `vertx-core`.</violation>
</file>

<file name="samples/client/petstore/kotlin-enum-default-value/build.gradle">

<violation number="1" location="samples/client/petstore/kotlin-enum-default-value/build.gradle:59">
P3: `moshi-adapters` is only referenced inside method bodies here (`EnumJsonAdapter` in `SerializerHelper.addEnumUnknownDefaultCase`), and no public signature exposes its types. Keep it as `implementation` to match the PR's stated rule; `api` leaks it to downstream consumers unnecessarily.</violation>
</file>

<file name="samples/client/petstore/kotlin-jvm-spring-2-webclient/build.gradle">

<violation number="1" location="samples/client/petstore/kotlin-jvm-spring-2-webclient/build.gradle:61">
P3: `reactor-core` is still `implementation`, but `Mono` appears in every generated public method signature. Mark it `api` too, for consistency with the rule this PR applies to other public-API types.</violation>
</file>

<file name="samples/client/others/kotlin-oneOf-anyOf-kotlinx-serialization-nonPublicApi/build.gradle">

<violation number="1" location="samples/client/others/kotlin-oneOf-anyOf-kotlinx-serialization-nonPublicApi/build.gradle:62">
P3: This `nonPublicApi` sample exposes no Retrofit or kotlinx-serialization types in its public API, so these two `api` declarations leak dependencies to consumers for no reason. The fix belongs in `kotlin-client/build.gradle.mustache`: gate the `api` choice on `{{^nonPublicApi}}` and keep `implementation` when `nonPublicApi` is set, then regenerate this sample.</violation>
</file>

_{Reply with feedback, questions, or to request a fix.

View guided diff | Re-trigger cubic}

cubic-dev-ai · 2026-11-13T21:17:43Z

+    api "com.google.code.gson:gson:2.14.0"
    implementation "io.vertx:vertx-web-client:$vertx_version"
-    implementation "io.vertx:vertx-core:$vertx_version"
+    api "io.vertx:vertx-core:$vertx_version"


P2: vertx-web-client is still implementation, but ApiClient.handleResponse is a protected member whose parameter type is io.vertx.ext.web.client.HttpResponse. That is the same kind of public-signature leak this PR fixes for vertx-core and gson, so subclassing consumers can still fail without redeclaring the dependency. Change vertx-web-client to api as well, in this sample and in the jvm-vertx block of the template.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At samples/client/petstore/kotlin-jvm-vertx-gson/build.gradle, line 60: <comment>`vertx-web-client` is still `implementation`, but `ApiClient.handleResponse` is a protected member whose parameter type is `io.vertx.ext.web.client.HttpResponse`. That is the same kind of public-signature leak this PR fixes for vertx-core and gson, so subclassing consumers can still fail without redeclaring the dependency. Change `vertx-web-client` to `api` as well, in this sample and in the `jvm-vertx` block of the template.</comment> <file context> @@ -55,9 +55,9 @@ test { + api "com.google.code.gson:gson:2.14.0" implementation "io.vertx:vertx-web-client:$vertx_version" - implementation "io.vertx:vertx-core:$vertx_version" + api "io.vertx:vertx-core:$vertx_version" implementation "io.vertx:vertx-lang-kotlin:$vertx_version" implementation "io.vertx:vertx-uri-template:$vertx_version" </file context>

cubic-dev-ai · 2026-11-13T21:17:43Z

    implementation "com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.22.1"
    implementation "io.vertx:vertx-web-client:$vertx_version"
-    implementation "io.vertx:vertx-core:$vertx_version"
+    api "io.vertx:vertx-core:$vertx_version"


P2: handleResponse in ApiClient exposes io.vertx.ext.web.client.HttpResponse in a protected signature, but vertx-web-client is still implementation. Subclasses that call this method will fail to compile without redeclaring vertx-web-client. Consider changing that line to api as well, matching the stated rule for HTTP types in public signatures.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At samples/client/petstore/kotlin-jvm-vertx-jackson/build.gradle, line 62: <comment>`handleResponse` in `ApiClient` exposes `io.vertx.ext.web.client.HttpResponse` in a protected signature, but `vertx-web-client` is still `implementation`. Subclasses that call this method will fail to compile without redeclaring vertx-web-client. Consider changing that line to `api` as well, matching the stated rule for HTTP types in public signatures.</comment> <file context> @@ -56,10 +56,10 @@ test { implementation "com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.22.1" implementation "io.vertx:vertx-web-client:$vertx_version" - implementation "io.vertx:vertx-core:$vertx_version" + api "io.vertx:vertx-core:$vertx_version" implementation "io.vertx:vertx-lang-kotlin:$vertx_version" implementation "io.vertx:vertx-uri-template:$vertx_version" </file context>

cubic-dev-ai · 2026-11-13T21:17:43Z

+    api "com.squareup.moshi:moshi-adapters:1.15.2"
    implementation "io.vertx:vertx-web-client:$vertx_version"
-    implementation "io.vertx:vertx-core:$vertx_version"
+    api "io.vertx:vertx-core:$vertx_version"


P2: io.vertx:vertx-web-client is still implementation, but its HttpResponse type appears in the protected handleResponse signature of the open ApiClient. Subclasses of ApiClient need that type on the compile classpath, so declare it as api like vertx-core. Apply the same change in the jvm-vertx block of build.gradle.mustache.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At samples/client/petstore/kotlin-jvm-vertx-moshi/build.gradle, line 62: <comment>`io.vertx:vertx-web-client` is still `implementation`, but its `HttpResponse` type appears in the protected `handleResponse` signature of the open `ApiClient`. Subclasses of `ApiClient` need that type on the compile classpath, so declare it as `api` like `vertx-core`. Apply the same change in the `jvm-vertx` block of `build.gradle.mustache`.</comment> <file context> @@ -56,10 +56,10 @@ test { + api "com.squareup.moshi:moshi-adapters:1.15.2" implementation "io.vertx:vertx-web-client:$vertx_version" - implementation "io.vertx:vertx-core:$vertx_version" + api "io.vertx:vertx-core:$vertx_version" implementation "io.vertx:vertx-lang-kotlin:$vertx_version" implementation "io.vertx:vertx-uri-template:$vertx_version" </file context>

cubic-dev-ai · 2026-11-13T21:17:43Z

    implementation "com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.22.1"
    implementation "io.vertx:vertx-web-client:$vertx_version"
-    implementation "io.vertx:vertx-core:$vertx_version"
+    api "io.vertx:vertx-core:$vertx_version"


P2: vertx-web-client stays implementation, but its HttpResponse type appears in the protected ApiClient.handleResponse signature. Subclasses of the open ApiClient will not compile without redeclaring it, so promote this to api too (also in the kotlin-client/build.gradle.mustache jvm-vertx block).

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At samples/client/petstore/kotlin-jvm-vertx-jackson-coroutines/build.gradle, line 63: <comment>`vertx-web-client` stays `implementation`, but its `HttpResponse` type appears in the protected `ApiClient.handleResponse` signature. Subclasses of the open `ApiClient` will not compile without redeclaring it, so promote this to `api` too (also in the `kotlin-client/build.gradle.mustache` jvm-vertx block).</comment> <file context> @@ -57,10 +57,10 @@ dependencies { implementation "com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.22.1" implementation "io.vertx:vertx-web-client:$vertx_version" - implementation "io.vertx:vertx-core:$vertx_version" + api "io.vertx:vertx-core:$vertx_version" implementation "io.vertx:vertx-lang-kotlin:$vertx_version" implementation "io.vertx:vertx-uri-template:$vertx_version" </file context>

cubic-dev-ai · 2026-11-13T21:17:43Z

    {{#jvm-vertx}}
    implementation "io.vertx:vertx-web-client:$vertx_version"
-    implementation "io.vertx:vertx-core:$vertx_version"
+    api "io.vertx:vertx-core:$vertx_version"


P2: vertx-web-client is still implementation, but its HttpResponse type appears in the protected handleResponse signature of the public open ApiClient. Subclasses of the generated client need it on the compile classpath, so declare it as api alongside vertx-core.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At modules/openapi-generator/src/main/resources/kotlin-client/build.gradle.mustache, line 238: <comment>`vertx-web-client` is still `implementation`, but its `HttpResponse` type appears in the protected `handleResponse` signature of the public open `ApiClient`. Subclasses of the generated client need it on the compile classpath, so declare it as `api` alongside `vertx-core`.</comment> <file context> @@ -235,7 +235,7 @@ dependencies { {{#jvm-vertx}} implementation "io.vertx:vertx-web-client:$vertx_version" - implementation "io.vertx:vertx-core:$vertx_version" + api "io.vertx:vertx-core:$vertx_version" implementation "io.vertx:vertx-lang-kotlin:$vertx_version" implementation "io.vertx:vertx-uri-template:$vertx_version" </file context>

cubic-dev-ai · 2026-11-13T21:17:44Z

-    implementation "com.squareup.moshi:moshi-kotlin:1.15.2"
-    implementation "com.squareup.moshi:moshi-adapters:1.15.2"
+    api "com.squareup.moshi:moshi-kotlin:1.15.2"
+    api "com.squareup.moshi:moshi-adapters:1.15.2"


P3: moshi-adapters is only used inside generated initializers and builder code (e.g. EnumJsonAdapter in the serializer helpers), not in any public signature. The PR description says such dependencies stay implementation. Either switch this to implementation (and the template in kotlin-client/build.gradle.mustache), or note in the PR why consumers need it on their compile classpath.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At samples/client/petstore/kotlin-default-values-jvm-retrofit2/build.gradle, line 60: <comment>`moshi-adapters` is only used inside generated initializers and builder code (e.g. `EnumJsonAdapter` in the serializer helpers), not in any public signature. The PR description says such dependencies stay `implementation`. Either switch this to `implementation` (and the template in `kotlin-client/build.gradle.mustache`), or note in the PR why consumers need it on their compile classpath.</comment> <file context> @@ -56,10 +56,10 @@ test { - implementation "com.squareup.moshi:moshi-kotlin:1.15.2" - implementation "com.squareup.moshi:moshi-adapters:1.15.2" + api "com.squareup.moshi:moshi-kotlin:1.15.2" + api "com.squareup.moshi:moshi-adapters:1.15.2" implementation "com.squareup.okhttp3:logging-interceptor:5.4.0" - implementation "com.squareup.retrofit2:retrofit:$retrofitVersion" </file context>

Suggested change

api "com.squareup.moshi:moshi-adapters:1.15.2"

implementation "com.squareup.moshi:moshi-adapters:1.15.2"

cubic-dev-ai · 2026-11-13T21:17:44Z

-    implementation "com.squareup.moshi:moshi-adapters:1.15.2"
-    implementation "com.squareup.okhttp3:okhttp:5.4.0"
+    api "com.squareup.moshi:moshi-kotlin:1.15.2"
+    api "com.squareup.moshi:moshi-adapters:1.15.2"


P3: moshi-adapters is only referenced inside method bodies here (EnumJsonAdapter in SerializerHelper.addEnumUnknownDefaultCase), and no public signature exposes its types. Keep it as implementation to match the PR's stated rule; api leaks it to downstream consumers unnecessarily.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At samples/client/petstore/kotlin-enum-default-value/build.gradle, line 59: <comment>`moshi-adapters` is only referenced inside method bodies here (`EnumJsonAdapter` in `SerializerHelper.addEnumUnknownDefaultCase`), and no public signature exposes its types. Keep it as `implementation` to match the PR's stated rule; `api` leaks it to downstream consumers unnecessarily.</comment> <file context> @@ -55,9 +55,9 @@ test { - implementation "com.squareup.moshi:moshi-adapters:1.15.2" - implementation "com.squareup.okhttp3:okhttp:5.4.0" + api "com.squareup.moshi:moshi-kotlin:1.15.2" + api "com.squareup.moshi:moshi-adapters:1.15.2" + api "com.squareup.okhttp3:okhttp:5.4.0" testImplementation "io.kotlintest:kotlintest-runner-junit5:3.4.2" </file context>

Suggested change

api "com.squareup.moshi:moshi-adapters:1.15.2"

implementation "com.squareup.moshi:moshi-adapters:1.15.2"

cubic-dev-ai · 2026-11-13T21:17:44Z

+    api "com.fasterxml.jackson.module:jackson-module-kotlin:2.22.1"
    implementation "com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.22.1"
-    implementation "org.springframework.boot:spring-boot-starter-webflux:$spring_boot_version"
+    api "org.springframework.boot:spring-boot-starter-webflux:$spring_boot_version"


P3: reactor-core is still implementation, but Mono appears in every generated public method signature. Mark it api too, for consistency with the rule this PR applies to other public-API types.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At samples/client/petstore/kotlin-jvm-spring-2-webclient/build.gradle, line 61: <comment>`reactor-core` is still `implementation`, but `Mono` appears in every generated public method signature. Mark it `api` too, for consistency with the rule this PR applies to other public-API types.</comment> <file context> @@ -56,9 +56,9 @@ test { + api "com.fasterxml.jackson.module:jackson-module-kotlin:2.22.1" implementation "com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.22.1" - implementation "org.springframework.boot:spring-boot-starter-webflux:$spring_boot_version" + api "org.springframework.boot:spring-boot-starter-webflux:$spring_boot_version" implementation "io.projectreactor:reactor-core:3.8.6" testImplementation "io.kotlintest:kotlintest-runner-junit5:3.4.2" </file context>

cubic-dev-ai · 2026-11-13T21:17:44Z

+    api "org.jetbrains.kotlinx:kotlinx-serialization-json:1.11.0"
    implementation "com.squareup.okhttp3:logging-interceptor:5.4.0"
-    implementation "com.squareup.retrofit2:retrofit:$retrofitVersion"
+    api "com.squareup.retrofit2:retrofit:$retrofitVersion"


P3: This nonPublicApi sample exposes no Retrofit or kotlinx-serialization types in its public API, so these two api declarations leak dependencies to consumers for no reason. The fix belongs in kotlin-client/build.gradle.mustache: gate the api choice on {{^nonPublicApi}} and keep implementation when nonPublicApi is set, then regenerate this sample.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At samples/client/others/kotlin-oneOf-anyOf-kotlinx-serialization-nonPublicApi/build.gradle, line 62: <comment>This `nonPublicApi` sample exposes no Retrofit or kotlinx-serialization types in its public API, so these two `api` declarations leak dependencies to consumers for no reason. The fix belongs in `kotlin-client/build.gradle.mustache`: gate the `api` choice on `{{^nonPublicApi}}` and keep `implementation` when `nonPublicApi` is set, then regenerate this sample.</comment> <file context> @@ -57,9 +57,9 @@ test { + api "org.jetbrains.kotlinx:kotlinx-serialization-json:1.11.0" implementation "com.squareup.okhttp3:logging-interceptor:5.4.0" - implementation "com.squareup.retrofit2:retrofit:$retrofitVersion" + api "com.squareup.retrofit2:retrofit:$retrofitVersion" implementation "com.squareup.retrofit2:converter-kotlinx-serialization:$retrofitVersion" implementation "com.squareup.retrofit2:converter-scalars:$retrofitVersion" </file context>

cubic-dev-ai · 2026-11-13T21:17:45Z

@@ -156,33 +156,33 @@ dependencies {
    {{#moshi}}


P3: moshi-adapters is used only by internal serializer implementation, so publishing it as api unnecessarily puts it on every consumer's compile classpath. Keep this dependency as implementation in both Moshi branches; only Moshi core (via moshi-kotlin or moshi) is part of the generated public API.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At modules/openapi-generator/src/main/resources/kotlin-client/build.gradle.mustache, line 160: <comment>`moshi-adapters` is used only by internal serializer implementation, so publishing it as `api` unnecessarily puts it on every consumer's compile classpath. Keep this dependency as `implementation` in both Moshi branches; only Moshi core (via `moshi-kotlin` or `moshi`) is part of the generated public API.</comment> <file context> @@ -156,33 +156,33 @@ dependencies { - implementation "com.squareup.moshi:moshi-kotlin:1.15.2" - implementation "com.squareup.moshi:moshi-adapters:1.15.2" + api "com.squareup.moshi:moshi-kotlin:1.15.2" + api "com.squareup.moshi:moshi-adapters:1.15.2" {{/moshiCodeGen}} {{#moshiCodeGen}} </file context>

cubic-dev-ai Bot reviewed Nov 13, 2026

View reviewed changes

Navigation Menu

Repository navigation

[KOTLIN] Declare public-API HTTP/JSON/date dependencies as api in the Gradle template - #25665

[KOTLIN] Declare public-API HTTP/JSON/date dependencies as api in the Gradle template#25665
Inf1mum wants to merge 1 commit into
OpenAPITools:masterfrom
Inf1mum:fix/25576-kotlin-api-deps

Inf1mum commented Nov 13, 2026 •

edited by cubic-dev-ai Bot

Loading

Uh oh!

cubic-dev-ai Bot left a comment

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

	api "com.squareup.moshi:moshi-adapters:1.15.2"
	implementation "com.squareup.moshi:moshi-adapters:1.15.2"

Conversation

Inf1mum commented Nov 13, 2026 • edited by cubic-dev-ai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What

Why api and not an option flag

Verification

Summary by cubic

Uh oh!

cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot Nov 13, 2026

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Inf1mum commented Nov 13, 2026 •

edited by cubic-dev-ai Bot

Loading

Why `api` and not an option flag