-
-
Notifications
You must be signed in to change notification settings - Fork 7k
New generator for Scala3 + sttp4 + jsoniter-scala #20006
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
base: master
Are you sure you want to change the base?
Conversation
thanks for the PR what about adding samples similar to |
Let me do just that! There's also a problem with classes generated having the same name with only case of some letters being different, that leads to warnings like this
and that's what does, in fact, happen on MacOS X. I'm wondering where I could tune that so that |
users can use |
That does not seem to work for top level classes with *Api suffix, I tried both: I still get:
and generated classes are: object LDAPApi {
def apply(baseUrl: String = "http://your-mattermost-url.com") = new LDAPApi(baseUrl)
}
class LDAPApi(baseUrl: String) {
... operations ... in object LdapApi {
def apply(baseUrl: String = "http://your-mattermost-url.com") = new LdapApi(baseUrl)
}
class LdapApi(baseUrl: String) {
... operations ... in {{#operations}}
object {{classname}} {
def apply(baseUrl: String = "{{{basePath}}}") = new {{classname}}(baseUrl)
}
class {{classname}}(baseUrl: String) { |
Ok, I fixed the I'll take a look at |
This is not dead btw, I'm fine-tuning the generator by generating working libraries for a) and b) are done, stripe is a bit tricky, d) and e) are close to working. |
@lbialy thanks for the update. let us know if you need help from us to move this forward. |
also cc @flsh86 and @chameleon82 for their feedback do we need another generator for |
I'm of the opinion that it should be the default for Scala 3 but I guess we can't just drop circe/json4s, people might be using that. On the other hand scala-sttp and scala-sttp4 seem to generate broken code for all form-based stuff and I'm in the process of completely rewriting that because it wasn't even compiling. There's also the oas 2 vs oas 3 thing between collection format and style/expand that requires handling and isn't done in any of the scala generators (just oas 2 / swagger is supported). I think I also spotted an issue in specs that have multiple auth styles - all of them are required simultaneously in the generated code so I'm working on fixing that too. |
Thanks for supporting scala3 community and making those changes @lbialy ! I do believe that might be better to keep one generator That sounds more complicated than having 2 generators, but I believe it will help to drop scala 2.13 support in the future without deprecating generator, while keeping better maintainance. Regarding |
@lbialy can you please add samples similar to ./bin/configs/scala-sttp4.yaml and add the new sample folder to the workflow (https://github.com/OpenAPITools/openapi-generator/blob/master/.github/workflows/samples-scala.yaml)? |
@lbialy Yeah, sure. I had to switch my attention to another task but I'm still working on this. @chameleon82 I don't think it would make sense to merge Scala 2 and Scala 3 versions exactly because of the maintenance effort required. Let me elaborate a bit. The implementations for Scala 2 are using an untyped mechanism that takes collections of |
Thanks so much for your work on this @lbialy! Sorry for the very naive question, I haven't looked at the code yet, but without making this PR about supporting simultaneously both Scala 2 & Scala 3, do you think any of your code here could benefit the Scala 2 version? Thinking specifically about |
This work is being continued by my peer from SoftwareMill - @Kamil-Lontkowski who is building the missing uniform and compile-time-safe mechanism to serialize function arguments to path params and forms. That functionality was a bit borked in all previous implementations as far as I know. Is |
Oops, my bad I misread your previous comments, I thought that your rewrite would enable the support for more features given the different approach |
It will support more features from v3 (for example regarding parameter serialization), but I did not look into inheritance and polymorphism yet so I am not able to tell if it could be supported. I will look into that but right now I don't really know. |
…rations, fix file response. change serialization from Map to Seq to avoid deleting duplicate keys
@Kamil-Lontkowski can you please PM me via Slack when you've time? https://join.slack.com/t/openapi-generator/shared_invite/zt-2wmkn4s8g-n19PJ99Y6Vei74WMUIehQA |
…kie serialization support
Scala sttp4 jsoniter wip
Ok, so this has moved along a bit, here's report from @Kamil-Lontkowski: Here’s the English translation: Unfortunately, this is not finished, but I think we managed to solve a few problems for sure, and also, not everything has to be implemented by this code generator. What has been done:
What still needs to be done:Blockers:
Other issues:
Overall, it seems that Stripe requires a closer look at what’s actually there. For example, there are probably recursive types, which prevent jsoniter from creating codecs – it keeps running until memory runs out. Current status at commit
|
@Kamil-Lontkowski mentioned that we should probably try and get this merged as it's usable for many cases already and then start fixing bugs as they show up in real use cases. I know I would still like to get more complex things like full Stripe API library working, albeit it seems that they are using out-of-openapi-spec things there that can be now handled by providing custom typeclass instances for the new serialization mechanics Kamil has built. There are some upstream issues like the enum naming logic. Maybe we should open issues against that, I'll try to find some time to do that but definitely not in the scope of this PR. |
Could we get this reviewed? 👓 |
If there would be a possibility to get this merged it would be awesome :) We're almost there with sttp-client 4 release (the - hopefully - final RC is now published), so having a generator would be a perfect complement to the release. Also, @wing328 if there's something that we could do on our side to streamline the process, just let us know! |
@lbialy , @Kamil-Lontkowski I've rawly reviewed the code and found - there is not much difference with @wing328 there are quite differences between Scala2 and Scala3, need your suggestion how we can continue on it? Maybe we can have @Kamil-Lontkowski please add examples to see if those passing tests as @wing328 suggested in the beginning. @adamw on a side note, looking forward for sttp4 release :) It would be also great to have otel auto-instumentation for otel feature |
@chameleon82 the release is there, no auto-instrumentation though - I still do feel that's totally not in the "spirit" of Scala's ecosystem - where you rather opt into explicitly setting up dependencies, than classpath "magic". Still, it's a matter of adding a wrapper to your backend instance in the setup of your app, so the overhead should be quite minimal :) |
bump! |
May I suggest a different approach? The current sttp4 generator is not working with the final release version, anyways. I made some changes to use it in-house, which I wanted to make into a pull request later this week, but...the current sttp4 generator is a mess, after all. To get it to correctly handle different "provides" and "consumes" and some types correctly is a major rewrite. I would suggest merging this pull request as is and use this as the basis for further development. The old sttp4 generator stays in place (for now) for everyone in need of an outdated and broken generator, that nonetheless uses other json parsers. I will then commit some time in this generator here to add the other parsers (and maybe scala 2 support) in a clean way and then this generator can become the new sttp4 (or better yet sttp) generator. |
may we have examples generated as @wing328 suggested? |
uh, I thought I did that, I'll take a look today |
I have extended scala-sttp4 to work with Scala 3 and latest sttp4 milestone (M19) using jsoniter-scala as the JSON layer. This work is based on scala-sttp4 generator and I've fixed a lot of issues and bugs it had. It's still far from being perfect and it does contain some hacks that were necessary to generate a compiling package for the Mattermost OpenAPI 4.0 doc (most notably - it tries to infer path parameters that are not provided in OAS document and types them as Strings). It works for the petstore example too. Are there any other sample OpenAPI docs I should test it against? I would like to provide a modern generator of efficient OpenAPI client libs for Scala 3 so I can improve this further if there are any issues.
I specifically submit this as a separate generator as I don't want to merge it with scala-sttp4 because maintenance of Scala 2 / Scala 3 generator would be quite troublesome, especially around enums. This could be also called
scala3-sttp4
.PR checklist
Commit all changed files.
This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
These must match the expectations made by your contribution.
You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example
./bin/generate-samples.sh bin/configs/java*
.IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
master
(upcoming7.x.0
minor release - breaking changes with fallbacks),8.0.x
(breaking changes without fallbacks)@clasnake @shijinkui @ramzimaalej @chameleon82 @Bouillie @Fish86