-
-
Notifications
You must be signed in to change notification settings - Fork 7k
New generator: kotlin-retrofit (lightweight, Android, coroutines) #3195
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
Conversation
…rator into kotlin-retrofit
* KotlinRetrofitCodegen no more uses AbstractKotlinCodegen (has wrong reserved word list) * support for default values for Api parameters
merge latest master
👍 Thanks for opening this issue! The team will review the labels and make any necessary changes. |
...penapi-generator/src/main/java/org/openapitools/codegen/languages/KotlinRetrofitCodegen.java
Outdated
Show resolved
Hide resolved
...penapi-generator/src/main/java/org/openapitools/codegen/languages/KotlinRetrofitCodegen.java
Outdated
Show resolved
Hide resolved
...penapi-generator/src/main/java/org/openapitools/codegen/languages/KotlinRetrofitCodegen.java
Outdated
Show resolved
Hide resolved
@kroegerama thanks for contributing a new generator. Have you considered incorporating the retrofit support via a The current |
cc Kotlin tech committe: @jimschubert (2017/09) , @dr4ke616 (2018/08) @karismann (2019/03) @Zomzog (2019/04) |
|
||
import static org.openapitools.codegen.utils.StringUtils.*; | ||
|
||
public class KotlinRetrofitCodegen extends DefaultCodegen implements CodegenConfig { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess AbstractKotlinCodegen
should be used here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope. AbstractKotlinCodegen has some wrong implementations. See my explanation here which is just one error I found in the abstract class.
We could merge the corrections in my Codegen into AbstractKotlinCodegen, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix found error in AbstractKotlinCodegen
is the right option. Plus, it can be done in separate PR to make contributions smaller -> get reviews easier -> merge faster.
BTW it's a nice contribution, looking forward to it 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed with @MatkovIvan to fix the bug in AbstractKotlinCodegen instead.
hey, thanks for the effort. Would be awesome if any kind of authenticationScheme is supported :) |
Hey. Great idea you have there. Do you have any ETA on release? Maybe i could somehow help push this further? |
Would love to see this generator gets merged into master. Thank you @kroegerama for his awesome work. |
merge from OpenAPITools/openapi-generator master
merge master into kotlin-retrofit
* add retrofit scalars converter for simple types * only add HttpLoggingInterceptor in Debug builds * initialize OkHttpClient lazy on non-main thread (see https://www.zacsweers.dev/dagger-party-tricks-deferred-okhttp-init/)
setCollectionType(additionalProperties.get(COLLECTION_TYPE).toString()); | ||
} | ||
|
||
if (CollectionType.LIST.value.equals(collectionType)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should have a warning that we're modifying typeMappings at this point, because it'll beak user's ability to define type mappings when using generator defaults.
import retrofit2.create | ||
import retrofit2.http.* | ||
import okhttp3.* | ||
import retrofit2.http.Headers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this necessary with the glob import above?
supportingFiles.add(new SupportingFile("proguard-rules.pro.mustache", "", "proguard-rules.pro")); | ||
supportingFiles.add(new SupportingFile("gitignore.mustache", "", ".gitignore")); | ||
|
||
supportingFiles.add(new SupportingFile("AndroidManifest.xml.mustache", "src/main", "AndroidManifest.xml")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: we may want to put Android options behind a CLI option. I scanned and didn't see any Android specific code in client files.
I agree that this would make more sense as a library option to the existing client generator. It seems that one of the major reasons it wasn't was because some keywords (like What might you need from the core team to get this into master? Maybe we could do it as a separate Beta generator and move to a library option later? |
Here is another PR to add retrofit2 as a library option to the Kotlin client generator: #4518 |
#4518 has been merged into master. Please give it a try. Closing this one for the time being. |
See #3135