Graddle plugin for OpenAPI generator

Created by: jmini

Capture of the discussion on Gitter:

@zwenza:

Is it already possible to use openapi-gen with gradle ?

@zwenza our artifacts aren't published. Once they are, you can create a gradle local plugin (buildSrc) see https://docs.gradle.org/current/userguide/custom_plugins.html Yes, you can try the SNAPSHOT. I've had issues with using snapshots as gradle plugins, though. It may be different for local plugins. I had previously suggested that we create a gradle plugin, as the code for such a plugin would end up being very similar to the Maven plugin (see https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator-maven-plugin/src/main/java/org/openapitools/codegen/plugin/CodeGenMojo.java#L331). But I think there were concerns about introducing a groovy artifact, I don't recall (it was about 2 years ago).

@jmini:

I know it might not be the standard way, but I guess gradle plugin can be normal java-jar built with maven? Gradle itself now uses groovy or kotlin

@jimschubert:

Yeah, it can be a java-jar. I think the concern was that groovy is a dynamic language and it's difficult to work with. I'd be happy to look at a Kotlin implementation, now that the Kotlin support in gradle is usable. I have looked at writing a gradle plugin a couple of times in the past, but the Kotlin support wasn't that great. I spent way more time trying to resolve syntax errors that shouldn't have been errors than writing code. I think the last time I gave it a try was about 9 months ago. Not having a gradle plugin is a blocker for my frontend team. I don't understand the reasoning fully, but they don't want to consume maven plugins from within gradle. I supposed it's likely there will be dependency resolution conflicts or maybe gradle's build/cache server has issues with embedding maven plugins.

@cbornet:

I think you can use a gradle task directly. See https://github.com/thebignet/swagger-codegen-gradle-plugin-example/blob/master/README.md So a plug-in is not really needed

@jimschubert:

@zwenza just be aware the the task-level implementation above is tightly coupled to the exposed api from the configurator. A benefit of having a gradle plugin encapsulating > this is that maintainers can provide clear feedback to changes to the interface, and buffer old config properties to new. I'm not saying to not use it. But for instance, if you target swagger-codegen as in the readme, then switch to openapi-generator (which is mostly exactly the same) and > you fail on warnings in your build, this task will fail as setLang(..) becomes setGeneratorName(..).

@zwenza:

yeah you are right. My idea was to test this and maybe try to create a small gradle plugin afterwards because I don't want that our company needs to copy this in every new project and if something changes each project would need to update their builds

Short term: If possible, I am in favor of a gradle plugin written in java, built with maven, hosted in this repository, similar to our maven plugin.