[BUG][KOTLIN] Dependencies whose types are in the client's public API are declared as implementation

Ouverte
  • Quelque chose ne va pas ?
#25,576 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
72/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
kotlin
Domaine
backend-api-design, build-system

Piste de recherche

Start with kotlin-client/build.gradle.mustache and compare its dependency scopes with the multiplatform and jvm-microprofile declarations mentioned in the issue. Check which generated public API types come from those dependencies, using the listed Gradle consumer reproducer and library variants as a guide. Change the exposed dependencies to api, then confirm the consumer compiles for the reproducer and affected options.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Bug Report Checklist
  • Have you provided a full/minimal spec to reproduce the issue?
  • Have you validated the input using an OpenAPI validator?
  • Have you tested with the latest master to confirm the issue still exists?
  • Have you searched for related issues/PRs?
  • What's the actual output vs expected output?
Description

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. A consumer doesn't get them on its compile classpath, so code that touches those members doesn't compile. With the default jvm-okhttp4, every Api takes client: Call.Factory, ApiClient.defaultClient is an OkHttpClient and Serializer.moshi is a Moshi; in jvm-retrofit2, jvm-vertx and jvm-spring-webclient even getPetById returns such a type.

multiplatform already declares Ktor as api, and jvm-microprofile does the same for Mutiny.

openapi-generator version

7.27.0, and master at d15b0164 (7.28.0-SNAPSHOT).

OpenAPI declaration file content or url

modules/openapi-generator/src/test/resources/3_0/petstore.yaml from this repo (validate reports no issues).

Generation Details
java -jar openapi-generator-cli.jar generate -g kotlin -i petstore.yaml -o client
Steps to reproduce

A consumer next to client:

// settings.gradle
includeBuild('../client')
// build.gradle
plugins { id 'org.jetbrains.kotlin.jvm' version '2.4.0' }
repositories { mavenCentral() }
dependencies { implementation 'org.openapitools:kotlin-client:1.0.0' }

import org.openapitools.client.apis.PetApi
import org.openapitools.client.infrastructure.ApiClient
import org.openapitools.client.infrastructure.Serializer

fun main() {
    val client = ApiClient.defaultClient.newBuilder().build()
    println(PetApi("http://localhost", client))
    println(Serializer.moshi.adapter(String::class.java).toJson("x"))
}

gradle compileKotlin on Gradle 8.14 and 9.8.2:

e: Cannot access class 'okhttp3.OkHttpClient'. Check your module classpath for missing or conflicting dependencies.
e: Cannot access class 'okhttp3.Call.Factory'. Check your module classpath for missing or conflicting dependencies.
e: Cannot access class 'com.squareup.moshi.Moshi'. Check your module classpath for missing or conflicting dependencies.

Expected: it compiles. Adding okhttp and moshi-kotlin to the consumer works around it.

Other options, same consumer setup with one call each (generated by master, Gradle 8.14):

options call missing class
moshiCodeGen=true Serializer.moshi.adapter(...) com.squareup.moshi.Moshi
serializationLibrary=gson Serializer.gson.toJson(...) com.google.gson.Gson
serializationLibrary=jackson Serializer.jacksonObjectMapper.writeValueAsString(...) com.fasterxml.jackson.databind.ObjectMapper
serializationLibrary=jackson, useJackson3=true Serializer.jacksonObjectMapper.writeValueAsString(...) tools.jackson.databind.json.JsonMapper
serializationLibrary=kotlinx_serialization Serializer.kotlinxSerializationJson kotlinx.serialization.json.Json
dateLibrary=threetenbp StoreApi().getOrderById(1L).shipDate?.year org.threeten.bp.OffsetDateTime
library=jvm-retrofit2 ApiClient().createService(PetApi::class.java).getPetById(1L).execute() retrofit2.Call
library=jvm-retrofit2 ApiClient().getTokenEndPoint()?.setClientId("x") org.apache.oltu.oauth2.client.request.OAuthClientRequest.TokenRequestBuilder
library=jvm-retrofit2, useRxJava3=true ...getPetById(1L).blockingGet() io.reactivex.rxjava3.core.Single
library=jvm-ktor, jackson PetApi(httpClientConfig = { it.expectSuccess = true }) io.ktor.client.HttpClientConfig
library=jvm-vertx api.getPetById(1L).onSuccess { } io.vertx.core.Future
library=jvm-spring-webclient PetApi(url).getPetById(1L).block() reactor.core.publisher.Mono
library=jvm-spring-restclient, useSpringBoot3=true Serializer.jacksonObjectMapper.writeValueAsString(...) com.fasterxml.jackson.databind.ObjectMapper

I didn't build the deprecated jvm-volley, which needs the Android SDK. Its GsonRequest is public and extends com.android.volley.Request, with volley and gson also declared as implementation.

Related issues/PRs

#14113 is about the scope of another dependency (slf4j-simple).

Suggest a fix

Use api for the libraries whose types the client exposes: moshi-kotlin, moshi-adapters and moshi, gson, jackson-module-kotlin (Jackson 2 and 3), kotlinx-serialization-json, threetenbp, okhttp, retrofit, the oltu client, rxjava, ktor-client-core, vertx-core, spring-boot-starter-webflux and spring-boot-starter-web. With that change the reproducer and every call in the table compile on Gradle 8.14 and 9.8.2. The Kotlin JVM plugin already provides the api configuration.

Langage dominant
Java
Étoiles
26.9k
Forks
7.8k
Merge moyen
2 j 10 h
PR mergées (30 j)
180

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de OpenAPITools/openapi-generator

Toutes les issues de OpenAPITools/openapi-generator

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.