Introducing OpenAPI Generator #3
Conversation
Signed-off-by: Ricardo Zanini <zanini@redhat.com>
Signed-off-by: Ricardo Zanini <zanini@redhat.com>
Signed-off-by: Ricardo Zanini <zanini@redhat.com>
ricardozanini
force-pushed
the
introduce-extension
branch
from
6c14afd
to
b603991
Compare
ricardozanini
requested review from
cescoffier,
FroMage,
michalszynkiewicz and
maxandersen
deployment/src/main/java/io/quarkiverse/openapi/generator/deployment/GeneratedOpenApiFile.java
Outdated
Show resolved
Hide resolved
...in/java/io/quarkiverse/openapi/generator/deployment/codegen/OpenApiGeneratorCodeGenBase.java
Outdated
Show resolved
Hide resolved
...n/java/io/quarkiverse/openapi/generator/deployment/template/QuteTemplatingEngineAdapter.java
Show resolved
Hide resolved
Signed-off-by: Ricardo Zanini <zanini@redhat.com>
ricardozanini
force-pushed
the
introduce-extension
branch
from
5c577e3
to
34742c1
Compare
Signed-off-by: Ricardo Zanini <zanini@redhat.com>
integration-tests/src/test/java/io/quarkiverse/openapi/generator/it/PetStoreTest.java
Outdated
Show resolved
Hide resolved
Signed-off-by: Ricardo Zanini <zanini@redhat.com>
|
Does it integrate with the Quarkus OpenAPI extension? Eg. Can you generate a client based on the output of |
|
It does not integrate automatically but can be a feature in the roadmap. :) If what you're asking is to use as an input a remote reference like |
| restClients.produce(new GeneratedOpenApiRestClientBuildItem(classInfo)); | ||
| hasGeneratedFiles = true; | ||
| } else if (classInfo.name().packagePrefix().equals(spec.modelPackage)) { | ||
| models.produce(new GeneratedOpenApiModelBuildItem(classInfo)); |
There was a problem hiding this comment.
maybe I'm misreading it, but wouldn't it make slightly more sense to have only one package name defined and created a name for the other by appending .model, or just use one package for both types of generated things?
It would simplify the config for users
There was a problem hiding this comment.
I was trying to mimic the exact configuration of the underlying library, but I agree that having only one property would simplify things for users. Let's do it.
There was a problem hiding this comment.
btw, are the build items produced here used?
There was a problem hiding this comment.
Not yet, but they will soon. I was experimenting with some things and decided to let them here for now.
...src/main/java/io/quarkiverse/openapi/generator/deployment/OpenApiGeneratorConfiguration.java
Show resolved
Hide resolved
Signed-off-by: Ricardo Zanini <zanini@redhat.com>
Signed-off-by: Ricardo Zanini <zanini@redhat.com>
| # since the file name has a space, we use the URI representation of this space here to not break the properties file | ||
| quarkus.openapi-generator.spec."open%20weather.yaml".base-package=org.acme.openapi.weather |
There was a problem hiding this comment.
maybe we could allow "open weather.yaml" and encode for the user it as it's done for paths?
There was a problem hiding this comment.
@michalszynkiewicz I had problems adding properties with spaces in the keys. It won't get read correctly. That's why I kept the encoding here to show how end-users should do this.
EDIT: actually, the IDE complains about the formatting style only. One should either add \\uu20u ASCII code representation of the space or use just encode via URL.
There was a problem hiding this comment.
btw, we have a nice wrong message for them as well:
The config property quarkus.openapi-generator.spec."open%20weather.yaml".base-package is required but it could not be found in any config source
Signed-off-by: Ricardo Zanini <zanini@redhat.com>
|
Is this the same PR I reviewed in quarkus core a while back? |
|
More or less the same thing, yes. I want to release a first version of the extension supporting a simple use case (sync REST) and adding more as we go and receive feedback. |
Minimal use case to add OpenAPI Rest Client generation for Quarkus.