[BUG] Kotlin generator: generateOneOfAnyOfWrappers=true leads to broken code

[andreas-umbricht]

Description

While using the Kotlin generator in a Android Project with "generateOneOfAnyOfWrappers=true", the generator generates code with the Gson Library even tough it should be Moshi by default(?). After including the Gson Library to the project, it still failed. Partly because of invalid naming of variables. As you can see in the picture below, on line 37 and 38, the generates variables are interpreted by kotlin as extension functions. So this won't compile.

To start from the beginning: We received a new OpenAPI Spec from our server team. The spec contains some "OneOf" relations. The file itself should be valid, since our iOS team was able to generate the desired code with openapi-generator generate -i Common/MeteoMapsAPI/meteomapsapi.json -g swift5 -o Common/MeteoMapsAPI --model-name-prefix SRF --additional-properties=projectName=MeteoMapsAPI,generateAliasAsModel=true.
If we (Android team) run the generator without "generateOneOfAnyOfWrappers=true", an error get's thrown @JsonClass can't be applied to ch.srf.meteo.data.meteomap.model.MeteoMapLayer: must be a Kotlin class. This makes sense looking into the generated code:

So I guess, the approach of using "generateOneOfAnyOfWrappers=true" should be correct?

The full OpenAPI declaration file can be found below.

openapi-generator version

7.9.0, 7.8.0

OpenAPI declaration file content or url

meteomap-api.json

Generation Details

    val generateMeteoMap by registering(GenerateTask::class) {
        generatorName.set("kotlin")
        .....
        configOptions.set(apiConfigOptions)
        additionalProperties.set(
            mapOf(
                "enumPropertyNaming" to "UPPERCASE",
                "useCoroutines" to "true",
                "moshiCodeGen" to "true",
                "generateOneOfAnyOfWrappers" to "true",
            )
        )
        library.set("jvm-retrofit2")
    }

Steps to reproduce

If you run the generator either with Gradle or via CLI with the attached OpenAPI declaration file (which should be valid in my opinion), the error occures.