Java/Scala (maybe Akka?) code generator about generator HOT 20 CLOSED

@ignasi35 would you be interested in that? Or you may know someone who can be 😉

from generator.

I just started working on it. I'll update here any feedback

from generator.

@fmvilas is there any specific reason why you didnt copy the Swagger/OpenApi generator here as well?

Since the AsyncApi is quite similar to OpenApi I think that copying the generator might get the code generation history like 80% there and (hopefully) only requires minor adaptations ...

EDIT: I take back my proposal. I would rather like to ask you if you have considered splitting your NodeJs generator into a parsing/preprocessing part and the actual generator like it is for OpenApi to make pluggable.

from generator.

Hi @carocad. I was actually thinking on following the same approach as I did with the OpenAPI Node.js code generator, where you can customize the template. Then it would be a matter of offering different templates for different languages/frameworks.

The problem with Java is that it's been a long time since I don't use the language (last time was Java 2 😅) and it's hard for me to come up with a working example.

I would just need a minimal working example to be able to do it. How are you with Java/Scala? Maybe you can help?

EDIT: Actually the templates feature was done by @richardklose, so kudos to him.

from generator.

You can read more about templates here: https://github.com/fmvilas/swagger-node-codegen/blob/master/templates/README.md

from generator.

@fmvilas oh I didnt see that you already have a templating engine there. I am interested in the Java part and I might end up doing an implementation. However I cannot promise that it will be soon nor that it will be made open source ... (company decision not (entirely) mine).

I will keep in touch for any news about it ;)

PS: Java 2 ?! That is like light years away 😄

from generator.

I understand that you may have some company restrictions, but let me tell you it doesn't need to do anything special, just a bootstrap project, so no company-related stuff will end up there. Actually I think it should be pretty simple to make it easier for people to customize it.

Let me know if you are interested. It doesn't need to be now.

from generator.

Hi @fmvilas I want to collaborate on a java implementation. As I'm a Spring framework lover I'd tell you thats the best option for java world(Am I not right :))

this is the project page https://cloud.spring.io/spring-cloud-stream/
as a consequence this will support only the protocols as the project support.

I read in the contribute page I should use https://github.com/asyncapi/generator but i don't see yet the migration for nodejs.

any advice here

from generator.

I have been following this repo, I'm really interested in an AsyncAPI to Java generator. I have a small lib that makes it easy to create API implementations from API specs in Java (https://github.com/intendia-oss/autorest) and a utility to generate Java API interfaces from OpenAPI (https://github.com/ibaca/autorest-openapi, apis-guru friendly 😉). I'll try to update in the next days so it can generate service interface from AsyncAPI and then creating a stream request builder for AutoREST (SSE prototype here https://github.com/ibaca/autorest-streaming-example). Not sure this is what you expect, but might fit quite good. It should work in the server (JRE), browsers clients (GWT) and even in android (example here https://github.com/ibaca/autorest-nominatim-example/).

from generator.

I read in the contribute page I should use asyncapi/generator but i don't see yet the migration for nodejs.

You're right. I didn't perform the Nodejs migration yet. It should be mostly what's here: https://github.com/asyncapi/node-codegen. Instead, create a Java project of your flavor, with the difference that now Handlebars helpers and partials are inside the template directory, e.g: templates/java-spring, and also there are some changes in the pattern you need to use on filenames when you want them to be repeated for each topic, e.g: templates/java-spring/src/.../topic-handlers/$$topic$$.java.

I'll try to update in the next days so it can generate service interface from AsyncAPI and then creating a stream request builder for AutoREST (SSE prototype here ibaca/autorest-streaming-example). Not sure this is what you expect, but might fit quite good. It should work in the server (JRE), browsers clients (GWT) and even in android (example here ibaca/autorest-nominatim-example).

That would also work. Feel free to ping me in your repo if you need help!

from generator.

Hi @fmvilas I'm having a hard time doing something similar to what is in file __service.js
for some reason I'm getting nothing for this block
{{topic.serviceName}}.{{topic.publish.operationId}}

BTW i have no idea how you are generating serviceName & publish.operationId

regards

from generator.

inspecting the config object in registerPartials method this is what I get:
{ asyncapi: { asyncapi: '1.0.0', info: { title: 'Streetlights API', version: '1.0.0', description: 'The Smartylighting Streetlights API allows you\nto remotely manage the city lights.\n', license: { name: 'Apache 2.0', url: 'https://www.apache.org/licenses/LICENSE-2.0' }, descriptionAsHTML: '<p>The Smartylighting Streetlights API allows you\nto remotely manage the city lights.</p>\n' }, baseTopic: 'smartylighting.streetlights.1.0', servers: [ { url: 'api.streetlights.smartylighting.com:{port}', scheme: 'mqtt', description: 'Test broker', variables: { port: { description: 'Secure connection (TLS) is available through port 8883.', default: '1883', enum: [ '1883', '8883' ], descriptionAsHTML: '<p>Secure connection (TLS) is available through port 8883.</p>\n' } }, descriptionAsHTML: '<p>Test broker</p>\n' } ], topics: { 'smartylighting.streetlights.1.0.event.lighting.measured': { publish: { summary: 'Inform about environmental lighting conditions for a particular streetlight.', payload: { type: 'object', properties: { lumens: { type: 'integer', minimum: 0, description: 'Light intensity measured in lumens.', descriptionAsHTML: '<p>Light intensity measured in lumens.</p>\n' }, sentAt: { type: 'string', format: 'date-time', description: 'Date and time when the message was sent.', descriptionAsHTML: '<p>Date and time when the message was sent.</p>\n' } } }, summaryAsHTML: '<p>Inform about environmental lighting conditions for a particular streetlight.</p>\n', descriptionAsHTML: '', generatedPayloadExample: '{\n "lumens": 0,\n "sentAt": "2018-10-31T03:03:25Z"\n}' } } }, components: { messages: { lightMeasured: { summary: 'Inform about environmental lighting conditions for a particular streetlight.', payload: { type: 'object', properties: { lumens: { type: 'integer', minimum: 0, description: 'Light intensity measured in lumens.', descriptionAsHTML: '<p>Light intensity measured in lumens.</p>\n' }, sentAt: { type: 'string', format: 'date-time', description: 'Date and time when the message was sent.', descriptionAsHTML: '<p>Date and time when the message was sent.</p>\n' } } }, summaryAsHTML: '<p>Inform about environmental lighting conditions for a particular streetlight.</p>\n', descriptionAsHTML: '', generatedPayloadExample: '{\n "lumens": 0,\n "sentAt": "2018-10-31T03:03:25Z"\n}' } }, schemas: { lightMeasuredPayload: { type: 'object', properties: { lumens: { type: 'integer', minimum: 0, description: 'Light intensity measured in lumens.', descriptionAsHTML: '<p>Light intensity measured in lumens.</p>\n' }, sentAt: { type: 'string', format: 'date-time', description: 'Date and time when the message was sent.', descriptionAsHTML: '<p>Date and time when the message was sent.</p>\n' } }, generatedExample: '{\n "lumens": 0,\n "sentAt": "2018-10-31T03:03:25Z"\n}' }, sentAt: { type: 'string', format: 'date-time', description: 'Date and time when the message was sent.', generatedExample: '"2018-10-31T03:03:25Z"' } } }, __commonPrefix: 'smartylighting.streetlights.1.0.event.lighting' }, target_dir: '/Users/melianr/dev/asyncapi/st-1', template: 'java-spring', templates: '/Users/melianr/dev/asyncapi/generator/templates/java-spring', package: { name: 'streetlights-api' } }

from generator.

You're right. That's something specific from the old implementation. You might want to get them from x-service-name (in the topic object) and x-operation-id (in the operation object) for now.

An example:

topics:
  user/signup:
    x-service-name: User
    publish:
      x-operation-id: publishSignup
      summary: Inform about environmental lighting conditions for a particular streetlight.
      payload:
        ...

In regard to operationId, we're gonna include it in the next version, so that could be changed afterward.

from generator.

great.

what should be the workflow to submit PRs: from a forked master to master or same repo to develop branch ?

from generator.

Same repo on develop branch. Thanks!

from generator.

hi @fmvilas you can see first changes here https://github.com/asyncapi/generator/compare/develop...rmelian:develop?expand=1
I just added support for consuming(publish) messages from RabbitMQ.
Now will work on sending messages(subscribe)

Question:
Is there currently a way to get additional parameters from CLI. For example
ag asyncapi.yml java-spring -maven
ag asyncapi.yml java-spring -gradle

from generator.

@rmelian awesome stuff. Feel free to create a PR so we can leave comments.

Is there currently a way to get additional parameters from CLI.

Not yet, but would be nice to have it. Open an issue in the generator repo if you feel it's needed.

Thanks for all the work you're doing!

from generator.

@fmvilas PR sent #7

from generator.

Really looking forward for an Akka HTTP generator!

from generator.

I'll close this issue as it was about AsyncAPI 1 and discussion about current template pain points and support for 2.0 happen here #134

from generator.