Improve openapi-client sub-generator

[ecostanzi]

Overview of the feature request

The current implementation of openapi-client wraps the openapi-generator-cli npm package. It generates the client code by running the following command via shelljs:

java -Dmodels -Dapis -DsupportingFiles=ApiKeyRequestInterceptor.java,ClientConfiguration.java -jar /project/sb/node_modules/@openapitools/openapi-generator-cli/bin/openapi-generator.jar generate -g spring -t....

The problem:
The developers cannot customize the generation command and the openapi templates. The openapi-generator-cli plugin is blackboxed by the sub-generator and there's no change to customize the generation process.

Improvements:

1. Add the generation script command in the scripts section of package.json file. Openapi-client command will modify the package.json in this way:

"scripts":{
	...
	"openapi-client:apidocs": "openapi-generator generate -g spring -Dmodels -Dapis -DsupportingFiles  -t swagger-codegen/libraries/spring-cloud  --library spring-cloud  -i http://localhost:8081/services/jhipster/v2/api-docs --artifact-id apidocs --api-package com.mycompany.myapp.client.apidocs.api --model-package com.mycompany.myapp.client.apidocs.model --type-mappings DateTime=OffsetDateTime,Date=LocalDate  --import-mappings OffsetDateTime=java.time.OffsetDateTime,LocalDate=java.time.LocalDate -DdateLibrary=custom,basePackage=com.mycompany.myapp.client,configPackage=com.mycompany.myapp.client.apidocs,title=apidocs --skip-validate-spec"
}

With this modification the client code can be regenerated by simply typing

npm run openapi-client:apidocs

This is also suggested in the openapi-generator-cli plugin documentation

2. The openapi templates can be copied into the jhipster project workspace. This allows to customize the default ones and maybe add more if necessary

Motivation for or Use Case

I think that at the moment the sub-generator wraps "too much" the openapi client. This is not how usually jhipster works. Developers will have the chance to modify the generation parameters based on what they need.

Let me know what you think. I already started working and will submit a PR soon.

Related issues or PR

#10491

• Checking this box is mandatory (this is just to show you read everything)

[ersinciftci]

Any reason to not add it to swagger.gradle/pom.xml as a task instead of adding it to package.json? We already have a task that generates the server code in swagger.gradle/pom.xml, we can add another task that generates the client code as well.

[cbornet]

Indeed. Calling it from the JVM tools would be even better since OpenAPI-generator is a jar after all. For Maven we need to check if the plugin can be run outside of the build process.

[ecostanzi]

@ersinciftci I agree. The main problem so far is that each generated client has its own ClientConfiguration file. This file can be customized and should not be overwritten by the build process. I'll open another issue to discuss about it.

Meanwhile the current PR improves the current generation process. It will alse be useful when we will implement code generation for frontend.

[cbornet]

Indeed. Maybe this file should be put in .openapi-generator-ignore ?