Skip to content

Add Scala support with akka-http server and client #45

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.

Sign up for GitHub

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

Jump to bottom
Open
reid-spencer opened this issue Mar 22, 2018 · 24 comments
Open

Add Scala support with akka-http server and client #45

reid-spencer opened this issue Mar 22, 2018 · 24 comments

Comments

@reid-spencer
Copy link

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
Copy link
Contributor

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

@jmini
Copy link
Contributor

jmini commented Mar 22, 2018

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
Copy link
Author

reid-spencer commented Mar 22, 2018 via email

@jmini
Copy link
Contributor

jmini commented Mar 22, 2018 •
edited
Loading

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
Copy link
Contributor

jmini commented Mar 22, 2018

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
Copy link
Author

reid-spencer commented Mar 22, 2018 via email

@reid-spencer
Copy link
Author

@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
Copy link
Contributor

webron commented Mar 22, 2018

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

@reid-spencer
Copy link
Author

@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
Copy link
Contributor

webron commented Mar 22, 2018

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
Copy link
Contributor

jmini commented Mar 22, 2018

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
Copy link
Author

@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
Copy link
Contributor

jmini commented Mar 22, 2018

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
Copy link

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

@rbiersbach
Copy link
Contributor

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
Copy link

@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
Copy link
Author

reid-spencer commented Aug 19, 2018 via email

@rbiersbach
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link

joelvim commented Mar 19, 2019

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
Copy link
Contributor

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

@joelvim joelvim mentioned this issue Mar 19, 2019
Closed
@joelvim
Copy link

joelvim commented Mar 19, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@webron @joelvim @jmini @reid-spencer @HugoMario @rbiersbach @sean-kim-zocdoc