[REQ] Add support for Project Helidon

[tjquinno]

We (the Helidon team) would love to see support for Helidon added to OpenAPI Generator.

We can certainly provide information about Helidon and might also be able to contribute to this project if we got some help getting started.

[jmini]

Would you use MicroFramework or MicroProfile?

If I understand It correctly:

1. Helidon SE: MicroFramework is really specific to Helidon.
   So you need to write templates and to contribute them.

2. Helidon MP: MicroProfile is on top of JAX-RS.
   We have already templates for that:
   https://github.com/OpenAPITools/openapi-generator/tree/master/modules/openapi-generator/src/main/resources/JavaJaxRS/spec

For the moment we are generating old swagger annotations into this (to auto-generate the api based on the JAX-RS annotations), but you can turn this off (there is a parameter)

I am working on generating the Eclipse-MicroProfile-OpenAPI annotation instead.
Are you supporting them?

If you generate the JAX-RS annotation, can helidon be started and serve the requests?
If yes, adding hellion is about being able to select the app-server that you would like to use. I guess this could be controlled by the library option where you could say, I would like to use TomEE or Helidon or whatever.

For the JAX-RS generator, the impact of this library option would be mainly:

• Changing the generated POM
• Changing the generated README
• ... (maybe other minor changes)

Because at the end the JAX-RS code should looks the same regardless of the implementation.

Does this make sense?

[tjquinno]

We would like to support both Helidon MP (MicroProfile) and Helidon SE in the generator.

Helidon MP does support the MP OpenAPI annotations. I'm aware of the generator flag to turn off the generation of annotations entirely, which would make sense for us until you complete your work on the OpenAPI MP annotations.

As you described, I was expecting that the JAX-RS templates would work for Helidon MP. Helidon MP provides a server (not an app server) that will run the generated code so we would tailor the pom.xml and README accordingly. I am not yet sure what other changes, if any, would be needed.

Helidon SE uses a different programming model from Helidon MP, so we were expecting (and it makes sense) that we would need new code generation templates. SE also provides its own server, a different one from Helidon MP, so I guess that would be another choice of library that would make sense only for Helidon SE?

[jmini]

I am confused with the terminology. I do not know Helidon other than from twitter or a blog post.
I took them from https://helidon.io/

I would say library option is great for the Helidon MP (MicroProfile) which build on top of JAX-RS.
For that I would appreciate a pointer to a demo project (a pom serving an greeting resource that says hello-world, and some command to start it).
Then we can augment the existing JAX-RS generator to generate the Helidon variant of the existing JAX-RS.

Then for your other model (called "Helidon SE: MicroFramework" on your homepage), there you need to create a new generator. You can start with an existing java-server that you adjust (maybe the generator of the model classes is the same).

Sadly there is a lot of copy paste in our templates. This is because it is hard to share just a part of one generator.

[tjquinno]

Thanks for the continued help. Apologies for the confusion. I think you have understood MP (MicroProfile) and SE (MicroFramework) just right.

Here is an example Helidon MP application:
https://github.com/oracle/helidon/tree/master/examples/microprofile/hello-world-implicit The README.md describes building, running, and accessing the app.

This one https://github.com/oracle/helidon/tree/master/examples/microprofile/openapi-basic shows the OpenAPI support in case that's helpful.

Let me know if I can explain further about the examples or Helidon.

Based on my understanding from reading the generator doc and starting to look at the code -- and from your comments here -- I agree that we'd need a new generator for Helidon SE. I'll be continuing to look into that.

[jmini]

@tjquinno: I am trying the openapi-basic, following the readme there.

I get:

[ERROR] Failed to execute goal on project helidon-examples-microprofile-openapi-basic: Could not resolve dependencies for project io.helidon.examples.microprofile:helidon-examples-microprofile-openapi-basic:jar:1.2.0-SNAPSHOT: Could not find artifact io.helidon.microprofile.bundles:helidon-microprofile-2.2:jar:1.2.0-SNAPSHOT -> [Help 1]

Any standalone example somewhere, relying only on released version?

[jmini]

I have checked out helidon-io/helidon@8626acb and now it seems to work...

[jmini]

It also work when checking out the 1.2.0 tag (commit helidon-io/helidon@cde7f33), but this is far from a standalone project: it relies on the parent pom defined in the project.

I have tried to transform it to a standalone project, but I did not succeed.

[tjquinno]

You say that the example is not a "standalone project." If by that you mean that you have to build the example yourself, then, yes, I agree. But you need to build only the specific example you want -- you do not have to build any other parts of Helidon -- so in that sense I would say it is standalone.

As you discovered, and as the examples doc here https://github.com/oracle/helidon/tree/release-1.2.0/examples describes, if you clone the repo you can checkout the release you want. Then build just the specific example you want.

I apologize for not pointing you to the link above sooner.

At this point are you able to do what you need to progress on this?

[jmini]

You say that the example is not a "standalone project." If by that you mean that you have to build the example yourself, then, yes, I agree. But you need to build only the specific example you want -- you do not have to build any other parts of Helidon -- so in that sense I would say it is standalone.

Maybe I picked the wrong world.
But right now, I am not able to reproduce the openapi-basic example in a separated project outside of the Helidon repo.

In my opinion this is because of the imbrication of the poms (and believe me I have tried).
A lot of stuff in openapi-basic/pom.xml is coming from the parent pom (and all parent-pom cascade)

I am working on adding different app-servers to the jaxrs-spec generator. So far I have added:

• Open-liberty
• Thorntail
• Quarkus

The generated code is the same, but the metadata (pom, some helper files, ...) are a little bit different.

To work on the open-liberty variant, the example micros-sample1 posted in #795 (comment) was very useful.

Can you provide an example that is not coupled to the parent poms (this is what I mean by standalone)?

I apologize for not pointing you to the link above sooner.

No worry.

[tjquinno]

Here is an updated pom.xml (as a .txt so GitHub would let me attach it) for the openapi-basic example. It does not rely on any parent poms.

Please try using this attachment instead of the file from the repository and it should work for you. It did for me locally. The rest of the project should work without change.
pom.xml.txt

[jmini]

I was able to start the server. Thank you for the example

[jmini]

Check PR #3901