Java code generation support

[benmccann]

I'd like to contribute towards PlayJava support. I don't expect you guys to do work towards adding Java support, but hopefully you don't mind me sending PRs for it. I'm a heavy contributor to Play, so I'm willing to help generally with Play/SBT. I think that supporting both Scala and Java I think it will help in getting more people using and testing the project and I'd much rather combine efforts than make a separate project for my Java code generation.

Quite a bit of the work is already being done from having Scala support. E.g. parsing the spec and generating an internal representation, which is really nice.

Some notes about what I'd need to do:

• Introduce SBT enum setting for Java vs Scala compilation. Should probably be added to PlaySwagger
• In SwaggerCompiler use the flag to generate only common files in Java mode like the routes file and generate everything in Scala mode
• Add generators for Java models and controllers
• Add scripted tests to verify output of code generation
• Have plugin automatically add spec2 and scalaz (Simplify dependency setup #29) and do this only in Scala mode

[benmccann]

@slavaschmidt @nmcb quick heads up that we were going to start working on this soon. @frantuma is beginning to examine the code

[slavaschmidt]

@benmccann @frantuma This is really great!
May be we should have a conversation in gitter about the common architecture of the plugin. We aim to have a plugin which should be usable for different specification formats, frameworks and languages. The idea is to parse all supported specification formats into the common AST and then use the AST to generate source code needed for specific framework and language.
In some sense, the final "plugin" would be just a configuration of "processor" part (only swagger for now) and generator (scala/java and play, akka-http is planned).
Does it make sense?

[slavaschmidt]

By the way, will you utilise some template engine for code generation?

[benmccann]

I figured we'd just do for the Java code whatever you are doing for the Scala code. I haven't looked that closely if you are using a template for the Scala stuff?

[slavaschmidt]

I started to use scalatra lately but not really satisfied with it. The main problem with any template engine i've found so far is that all of them are really HTML-related and not really good for source code generation. You could take a look in newnaming branch to see what i mean.

[benmccann]

I found a mustache template. Are you experimenting with it as an alternative to the scalatra stuff? I can't think of anything that'd be any better off the top of my head. https://github.com/zalando/play-swagger/blob/313e0fcbc0e7c364aaa53f6dfcf56aee13a6a350/compiler/src/main/resources/model.mustache

[frantuma]

@slavaschmidt If I got it right, you are currently using no templates in master and scalate in newnaming branch; I understand that you're getting issues with this approach caused by the limitations when dealing with source code generation and I'd like to share some thoughts even if I would need some more time to get a clear overall picture.

I have been investigating a bit, and it seems that the template approach is used widely, e.g. by swagger codegen (http://swagger.io/swagger-codegen/) which seems to use mustache. I believe other options could include django, liquid, freemarker, velocity.

In your current approach, and as you mention in earlier comment, I guess the idea is to have a set of parsers (for swagger, RAML, etc) getting out a specific model, then transformed to common AST; a generator engine would then take care of creating source code via configuration and language/tech specific templates.

This sounds right to me (with obvious limitations caused by bad/incomplete input and possible "infinite" scope of output), with possible focus on swagger/play as initial input/output. Also this differs from e.g. swagger-codegen because of the middle common model (they use swagger model "directly" I guess) and the scope including other definition sources;

The alternative would be to have single definition->code paths for each pair, this would allow probably to use existing libs in exchange with complexity etc.

As said I possibly need some more time, but in any case possibly the parser component for swagger could be using swagger-parser, keeping the swagger to AST transform, as possibly drafted in a really initial project https://github.com/unicredit/sbt-swagger-codegen

Please let me know what you think

[slavaschmidt]

@frantuma everything is correct. I was not aware about sbt-swagger-codegen, will take a look at it.

[josephearl]

For generating Java source you might want to check out https://github.com/square/javapoet