swagger-codegen-gradle-plugin icon indicating copy to clipboard operation
swagger-codegen-gradle-plugin copied to clipboard

Deprecation question!

Open SergeyPirogov opened this issue 7 years ago • 7 comments

In the readme, there is a phrase DEPRECATED? Could you clarify why and what is the substitution?

SergeyPirogov avatar Dec 22 '17 07:12 SergeyPirogov

As said in the second paragraph, see the swagger-codegen-gradle-plugin-example for creating a Gradle task to generate code with Swagger Codegen. This is a prefered way to generate code from Swagger as it is more flexible. It does not involve a plugin, allows better customisation and is not linked to a specific version of swagger codegen.

Is the actual README clear to you ? Maybe you could suggest a PR to make this deprecation warning more explicit ?

thebignet avatar Dec 22 '17 09:12 thebignet

Regarding your point about linking to an actual version of the codegen, we could always upgrade the codegen version by having this at the top of our build files.

buildscript {
    dependencies {
        classpath 'io.swagger:swagger-codegen:2.3.1'
    }
}

To prove that the plugin uses the correct version of codegen, run gradle buildEnvironment to get the below output showing that we're now using Swagger codegen v2.3.1.

+--- org.detoeuf.swagger-codegen:org.detoeuf.swagger-codegen.gradle.plugin:1.7.4
|    \--- gradle.plugin.org.detoeuf:swagger-codegen-plugin:1.7.4
|         \--- io.swagger:swagger-codegen:2.2.3 -> 2.3.1 (*)

I am not convinced this plugin needed to be deprecated. The whole point of a plugin is to abstract away the details involved so that we don't end up writing code within our build scripts.

radarsh avatar Feb 09 '18 11:02 radarsh

Thanks @radarsh, I haven't thought of overriding the version like so. Maybe I could give it a shot at modifying the plugin to see if everything works as expected.

thebignet avatar Feb 12 '18 10:02 thebignet

@thebignet - does this mean you are going to un-deprecate the plugin?

baynezy avatar Feb 12 '18 10:02 baynezy

I'd have to try @radarsh 's technique to see if there are any side effects. After all, the plugin will be compiled with a certain version and runtime will use another, there might be limitations. If all goes well, this could possibly mean un-deprecating the plugin.

Would that sound good to you ? Would you like to give it a try and make a PR ?

thebignet avatar Feb 12 '18 10:02 thebignet

Hello Did you tried @radarsh's technique? Any updates on un-deprecation? I agree with radarsh, i dont want To mix code in build script.

sag1 avatar Mar 30 '18 21:03 sag1

Sorry for the late reply, but I noticed that the swagger-codegen repo now has the maven plugin code built into it. There might be a way to add the gradle plugin to this repo too. Don't have much time at the moment, but if someone wants to give it a go, it should be farely straightforward.

The benefits I see is that the gradle plugin will be much more maintained this way and that the codegen version is accessible, so building the plugin against the up-to-date version will be easier. Of course, if there was a TravisCI build to drop the new version of the plugin on each release, it will be even better.

thebignet avatar Apr 24 '18 12:04 thebignet