openapi-generator

openapi-generator copied to clipboard

Description

I want to generate the model and the api, but compiling fails when compiling the generated files in org.openapitools.client.infrastructure. These classes are not needed so I would like to disable generating them in the first place

openapi-generator version

gradle plugin version 4.3.0

Command line used for generation

openApiGenerate { generatorName.set("kotlin")

inputSpec.set("$buildDir/openapi/api.yml)
outputDir.set("$buildDir/generated/openapi")

apiPackage.set("my.api")
modelPackage.set("my.model")

}

Suggest a fix/enhancement

Adding another configuration property to be able to disable the generation of the content of ``org.openapitools.client.infrastructure`

Hi, any news? We have a serious problem because we generate API in multiple modules and we run to the errors like Type org.openapitools.client.auth.HttpBearerAuth is defined multiple times: or Type org.openapitools.client.infrastructure.ApiClient$Companion$defaultBasePath$2 is defined multiple times:

I found that the error can be solved by packageName but still it'd be nice to skip the files

While trying to generate the infrastructure package without all the gradle and build config stuff that gets generated, I managed to get rid of that package with this config:

openApiGenerate {
    inputSpec = "api.json"
    outputDir = "$projectDir/api-client"
    generatorName = "kotlin"
    modelPackage = "acme.api.models"
    apiPackage = "acme.api"
    globalProperties = [
            apis: "",
            models: ""
    ]
}

The important part is defining those global properties with empty values, which instruct to generate everything related to that artifact (all apis and models, and nothing else). Refer to the Note section here

I hope that helps ;)

I'm yet to find a way not to generate the Gradle stuff :/

BTW, using the latest Gradle openapi-generator plugin.

@jimschubert @dr4ke616 @karismann @Zomzog @andrewemery @4brunu @yutaka0m

Would you accept a contribution for this? I guess we could introduce a new CLI option, and remove the infrastructure files from the supporting files depending on the option. How would you name this flag?

Hi, just to make sure that I understood the issue here, it's to remove the infrastructure imports when generating the api and models only?

@4brunu The main issue here is that lots of users the not need the generated ApiClient and its other classes in infrastructure, only APIs and models. So the generated could just skip generating that whole package.

However i did not realize that there can be references to the infrastructure code from APIs and models as well. At our company we use that retrofit2 library in the generated code, which doesn't really rely on the infrastructure folder. Except for CollectionsFormats.CSVParams etc. Maybe this could be a retrofit2-only option, but we still have to retain these CollectionFormats somehow.

So actually, is not that really feasible to remove the infrastructure folder in general. :(

I see, thanks for explaining. Yes, there are some references to the infrastructure, so this may not be feasible.

By the way, could you please share some use cases where you only want the models and api? Just curious

I think the main use case to have more control on how to configure your API client. Which kind of serialization would you like to use, authentication, interceptors, leveraging your DI, etc.

I see, thanks for the examples. One way to archive that is to use custom templates, although it's not ideal.

I have a use case where I used the infrastructure classes only as starting point, and now actually maintain only the model and API classes via code generation: https://github.com/docker-client/docker-remote-api

@cebbens Thank you very much for the note in docs!

I've ended up with a configuration that keeps infrastructure.CollectionFormats.kt file as it is referenced from every Retrofit Api class:

globalProperties.set(
    mapOf(
        "apis" to "",
        "models" to "",
        "supportingFiles" to "CollectionFormats.kt",
    ),
)

And if you're using the CLI and your configs are in a json file for example you can include CollectionFormats like this:

{
"globalProperties": {
    "apis": "",
    "models": "",
    "supportingFiles": ["CollectionFormats.kt"]
  }
}

My issue is that I have a Gradle project with multiple modules which can contain generated open API clients and I want some shared module that does translation of Open API infra client exceptions to my application specific exceptions.

Unfortunately each module (which is jar) can contain its own copy of infra classes org.openapitools.client.infrastructure which then leads to type conflicts in classpath.

So if I have 10 modules (jar) with generated clients I will have 10 classes copies org.openapitools.client.infrastructure.* for example org.openapitools.client.infrastructure.ClientException.

The better option would be to have org.openapitools.client.infrastructure.* in one library (jar) and client generated without org.openapitools.client.infrastructure.* but with dependency on this jar with infractructure.

Oh to have option to disable generation of infrastructure classes.

-- In gradle I also can control what generated classes to include through source-sets but it complicates things.

sourceSets {
    getByName("main") {
        java {
            srcDir(layout.buildDirectory.dir("generated/src/main/kotlin"))
        }
    }
}

Finally, my workaround to disable the generation of files in org.openapitools.client.infrastructure.* is using file .openapi-generator-ignore with content

# we do not need package [org.openapitools.client.infrastructure.*] to be generated
/**/org/openapitools/client/infrastructure/

More information about ignore file format