Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecation question! #58

Open
SergeyPirogov opened this issue Dec 22, 2017 · 7 comments
Open

Deprecation question! #58

SergeyPirogov opened this issue Dec 22, 2017 · 7 comments

Comments

@SergeyPirogov
Copy link

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

@thebignet
Copy link
Owner

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 ?

@radarsh
Copy link

radarsh commented Feb 9, 2018

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.

@thebignet
Copy link
Owner

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.

@baynezy
Copy link

baynezy commented Feb 12, 2018

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

@thebignet
Copy link
Owner

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 ?

@sag1
Copy link

sag1 commented Mar 30, 2018

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.

@thebignet
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants