OpenAPITools / OpenAPITools/openapi-generator

[REQ] Option to generate Gradle project with `build.gradle.kts` (Kotlin DSL) instead of `build.gradle` (Groovy DSL)

Open
#17,889 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Enhancement: Feature
Dominant language
Java
Stars
26.8k
Forks
7.7k
PR merge metrics
PR metrics pending

Description

Is your feature request related to a problem? Please describe.

When using the openapi-generator to generate a Kotlin project from an OpenAPI spec, it generates a Gradle project with build.gradle and settings.gradle files in the older Groovy format. It would be nice if there were a configuration option to have such a project generated with build.gradle.kts and settings.gradle.kts files (in the newer Gradle Kotlin DSL format) instead, since some of us prefer that, especially in Kotlin projects. I've searched existing GitHub issues for this, and I'm surprised that no one else has submitted this feature request yet.

Describe the solution you'd like

When invoking the generator, I'd like to be able to do something like this:

openApiGenerate {
    generatorName.set("kotlin")
    configOptions.set(mapOf(
        "gradleBuildDsl" to "kotlin" // as opposed to "groovy"
    ))
}

Describe alternatives you've considered

First of all, I checked whether such an option already existed in the documentation of the OpenAPI Kotlin Generator, but I found no mention of such a feature there.

I've looked for tools and plugins to automatically convert the generated Gradle project from Groovy DSL to Kotlin DSL, and I found GradleKotlinConverter, but it hasn't had a new release in almost 4 years, so it doesn't appear to be actively maintained. Also, having to run such a converter separately after having the automatic project generation would require additional setup work, would be slower and might potentially lead to conversion errors.

Additional context

The Kotlin DSL is increasingly becoming the preferred DSL for Gradle projects, and even officially so in the case of Android projects:

Kotlin is preferred over the Groovy for writing Gradle scripts because Kotlin is more readable and offers better compile-time checking and IDE support.

Although Kotlin currently offers better integration in Android Studio’s code editor when compared to Groovy, builds using Kotlin tend to be slower than builds using Groovy, so consider build performance when deciding whether to migrate.

Source: https://developer.android.com/build/migrate-to-kotlin-dsl

Also, when you're working on a Kotlin project anyway, it's more convenient to have the build configuration in the same language you're using for the source code in the project, instead of having to mentally switch back and forth between Kotlin and Groovy. And although there is a tradeoff between convenience and performance, it would be good to offer us the choice between the two, through use of such a config option. Also, the Kotlin DSL performance has already been improved in newer Gradle versions.

Thank you kindly for considering this.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the OpenAPI Kotlin Generator and its documented configuration options, then trace how it generates the Gradle build.gradle and settings.gradle files. Define the option's behavior for selecting Kotlin DSL versus Groovy DSL, and verify that the selected build.gradle.kts and settings.gradle.kts files are generated while the existing default remains available.

Written by the indexing model from the issue text.

Assessment

Tech stack
kotlin
Domain
build-system
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.