Documentation is a little confusing - Separation of client & server concerns

[jamfor352]

Hi,

I'm using this for the first time, but the documentation is a little confusing to me. For example:

https://docs.quarkiverse.io/quarkus-openapi-generator/dev/server.html and https://docs.quarkiverse.io/quarkus-openapi-generator/dev/client.html

both mention adding the same dependency/extension (which I think is wrong and should have -server and -client at the end?):

<dependency>
  <groupId>io.quarkiverse.openapi.generator</groupId>
  <artifactId>quarkus-openapi-generator</artifactId>
  <version>3.0.0-SNAPSHOT</version>
</dependency>

and setting the same properties:

for example:

quarkus.openapi-generator.codegen.input-base-dir=openapi-definitions
quarkus.openapi-generator.codegen.spec.petstore_json.base-package=org.acme

but it isn't really clear as to how I configure both concepts and handle different spec files? I would have thought client & server extensions would have their own dedicated properties, ie quarkus.openapi-generator.codegen.server.input-base-dir & quarkus.openapi-generator.codegen.client.input-base-dir to prevent clashing if both extensions were desired

A lot of microservices simultaneously need to call another microservices whilst also having their own server classes - what I'm not sure about is how to, in one microservice, only generate the server stub for spec A (with no client, because that's pointless for that microservice), and only generate the client code for spec B (with no server, as it'll never implement it). Both server & client documentation reference the same properties and extensions so it's unclear from the documentation how to configure each specific thing.

[mcruzdev]

Hi @jamfor352 thanks for creating the issue!

@carlesarnal shouldn't the documentation indicates the use of io.quarkiverse.openapi.generator:quarkus-openapi-generator-server?

@hbelmiro and @ricardozanini I think that to separate quarkus.openapi-generator.codegen.server.* and quarkus.openapi-generator.codegen.client.* makes sense.

Today, if I'm not wrong, the server looks the specification files from another location resources I think.

[ricardozanini]

@jamfor352 @mcruzdev Yes, we can add the client prefix to the client part in the config while keeping the backyard compatibility (so the remaining props should still work).

@carlesarnal can you review the server docs?

[mcruzdev]

Hi @jamfor352 and @ricardozanini I opened a pull request to solve this issue, this was a mistake on my side, after looking carefully, we were pointing to the same documentation after the changes in the doc.

@jamfor352 there are just two properties on server extension:

• quarkus.openapi.generator.spec=petstore-openapi.json
• quarkus.openapi.generator.base-package=io.petstore

It is more simple now!

[ricardozanini]

@mcruzdev @carlesarnal I think these props should be renamed to:

quarkus.openapi.generator.server.spec=petstore-openapi.json
quarkus.openapi.generator.server.base-package=io.petstore

[mcruzdev]

Is most easiest to change only the server side than change all client properties.

+1

[ricardozanini]

@carlesarnal can you this change, please?

[mcruzdev]

@ricardozanini if you want I can change this one in this weekend.