Add Scala support with akka-http server and client

[reid-spencer]

I intend to implement both the server and client side for akka-http, soonish, as I have time available. I'm aware of the various Scala support in the 2.0 project but none of it is based on the right technologies for our purposes. I will, however, endeavor to layer it so that Scala based code generation can be done in multiple ways. That is, I will factor in the request in swagger-codegen issue 3812. This ticket will effectively provide a 3.0 implementation for swagger-codegen issue 5900 .

I welcome all discussion here about combining efforts to create server and client generators that support reactive programming. Mostly they both need to be asynchronous non-blocking systems that implement backflow via Akka Streams. If I'm duplicating work (haven't seen it yet), please let me know!

[HugoMario]

no, this is not a duplicated issue and languages implementations for codegen 3.0.0 are always welcome

[jmini]

Do you need something from the existing scala Codegen? I could migrate them in this repo if you agree to have a look at the generated scala code (after migration). This might give you a basis that you can extend.

[reid-spencer]

I have already copied the AbstractScalaCodegen , the existing Akka client, and their templates. I will use these as the basis for the new code generators. I will probably have some vomits in my fork by the weekend.

On Mar 22, 2018, at 1:27 AM, Jérémie Bresson notifications@github.com wrote:

Do you need something from the existing scala Codegen? I could migrate them in this repo if you agree to have a look at the generated scala code (after migration). This might give you a basis that you can extend.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jmini]

This is great news!

When I copy the Codegen, I go through these steps: https://github.com/swagger-api/swagger-codegen/wiki/Swagger-Codegen-migration-(swagger-codegen-generators-repository)

For example it would be great to have all the scala stuff in the io.swagger.codegen.languages.scala package. => io.swagger.codegen.languages.scala.AbstractScalaCodegen and so on.

---

EDIT: I have noticed you know already that page. I just added 3 small sections:

• Top level class
• Naming convention
• Remove fields declaration hiding another field or variable

[jmini]

I can give you an other input for the Mustache to Handlebars conversion:

I try to keep this wiki page up to date: Swagger Codegen migration from Mustache and Handlebars templates.

If you are interested, I have created this class to help with the template migration: ConvertMustache.java. It is really raw and basic, but it does the job. Feedback is welcomed.

[reid-spencer]

Yes. That’s what I’m doing.

On Mar 22, 2018, at 1:55 AM, Jérémie Bresson notifications@github.com wrote:

This is great news!

When I copy the Codegen, I go through these steps: https://github.com/swagger-api/swagger-codegen/wiki/Swagger-Codegen-migration-(swagger-codegen-generators-repository)

For example it would be great to have all the scala stuff in the io.swagger.codegen.languages.scala package. => io.swagger.codegen.languages.scala.AbstractScalaCodegen and so on.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[reid-spencer]

@jmini - Thanks for all the pointers. I have a question: would it be acceptable to develop this in my own repository (not a fork) and use Service Locator to let swagger-codegen access it? I would like to retain IP rights. It would be licensed with Apache 2.0 license, same as this project.

[webron]

@reid-spencer it's an open source project, you can do whatever you want (within the license limitations).

[reid-spencer]

@webron - While that is true, the owners have commit and PR approval privilege that I do not have. If there's a policy that says "no external libraries" or other IP concerns that will prevent my changes from being accepted, I want to know about it sooner rather than later. But, sounds like that's not the case. So, onward I will go. Thanks for the feedback.

[webron]

Right, not everyone has write access, for understandable reasons. We process PRs regularly and try to make the best decision based on the community and project needs. Not really sure what you mean by "no external libraries" in this case, so difficult to respond to that.

[jmini]

I have a question: would it be acceptable to develop this in my own repository (not a fork) and use Service Locator to let swagger-codegen access it

The advantage of having a generator in the common project swagger-codegen-generators is that it will be available in the official distribution. It will be more visible to the community and you will get more feedback. This has also a cost: you need to communicate with the project. You need to wait for feedback and for review. You also need to accept some choices that were already made by the existing team. If you want to change something, you will need to convince the team.

If you develop something separated, you are on your own and probably more flexible. For the user of your lib: for maven-plugin usage, the users will need to add your lib as plugin dependency. For cli usage they will need to add your jar (and its dependencies) on the classpath.

[reid-spencer]

@jmini - Perhaps. I plan to modify swagger-codegen-generators and swagger-codegen just enough so that it all functions like the others. It's just that the templates and the actual CodegenConfig class is in another open source jar file that is added to swagger-codegen-generators dependencies like any other. Would that be okay?

[jmini]

I am not part of the team, I do not decide.

But I can give you my opinion: I do not think that it is the idea to add an additional dependency to swagger-codegen-generators. If you have a jar containing a CodegenConfig and the templates, it can be used in addition to swagger-codegen-generators or as replacement if you do not care about the generators provided there. You will use it in the maven plugin or in the cli jar.

[sean-kim-zocdoc]

Just wondering what the latest is on this. I can try to help out if needed. I need this for my work.

[rbiersbach]

Hi guys, I am thinking about implementing the akka http server generator for 3.0.0 too. @sean-kim-zocdoc @reid-spencer Did u already start with implementing and are u still interested? I would like to cooperate on this because it is my first code generator project.

[sean-kim-zocdoc]

@rbiersbach I was planning on getting to this around late September so if you can get this started now, that would be great!

[reid-spencer]

I am still interested but priorities have changed a bit for me. I'm flat out busy for months ahead. One of the things that happened in my review is that I really couldn't deal with the ancient design of the current swagger software and was thinking of just rewriting it in Scala, for scala. I may have to let that idea go though because I don't have much time to commit to this. When I do get some time, I will likely join in on helping with whatever you've come up with by then.

On Fri, Aug 17, 2018 at 3:27 PM, sean-kim-zocdoc notifications@github.com wrote:

@rbiersbach https://github.com/rbiersbach I was planning on getting to this around late September so if you can get this started now, that would be great!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/swagger-api/swagger-codegen-generators/issues/45#issuecomment-413992706, or mute the thread https://github.com/notifications/unsubscribe-auth/ABef4F5SwZqh3APPxFSi94Zd7-vpHnHwks5uRzUqgaJpZM4S2RgN .

[rbiersbach]

Ok guess I will start implementing the server generator for akka http now. @HugoMario Which branch/tag would be the best starting point for Open API 3.0?

[HugoMario]

hello @rbiersbach , for OAS 3.0 we're working on https://github.com/swagger-api/swagger-codegen-generators repo. Pleae, let me know if you have any doubt/question, you can reach me on https://gitter.im/swagger-api/swagger-codegen

[rbiersbach]

Just to keep u guys up to date: Work is done on the https://github.com/swagger-api/swagger-codegen-generators/tree/scala-generators branch

[rbiersbach]

A first version of the akka http server codegen has been merged to the master. Basic functionality is covered, but a lot of work is still open. If you want to help developing please contact me. I got some test code, that didn't fit the repo and will help alot. Not implemented yet are:

• cookie paramameters due to a bug in the CodegenOperation not providing any cookie params
• security
• generation of unit test stubs
• complex form data Also I am sure a lot of topics are open, that I did not think of.

[joelvim]

Hello, what is the status of this issue? I updated the akka-scala client generator to migrate from spray to akka http, updating the versions of the libs, but I didn't see this issue before doing it. Is this already done or not? I did this because it could be useful for us in the future, if it can be useful for you, my code is available here https://github.com/joelvim/swagger-codegen/tree/update-akka-scala. May I open a PR or is it useless? Best regards

[rbiersbach]

I only did work for the server generator, so I guess work for the client is welcome :)

[joelvim]

Ok, I opened the PR, let me know if it's ok or if I should change some things.