Users would previously be forced to extend their target generator and go through more complicated customization steps just to add new files to generated output.
This adds support for user-defined templates.
Users can now:
- add supporting files that aren't referenced in the target generator
- include additional templates for api/model and their docs and templates
- modify file extensions/suffixes for api/model (docs+tests)
Notes on the new feature:
- This is currently a "merge" operation. Existing definitions will be overwritten, but other template definitions will be untouched. This allows users to add files by default.
- To modify generated suffixes/extensions for others (not supporting files), may require inspection of source to exactly match the map key used in the target generator. e.g. "model_doc.mustache", "Doc.md" would output DogDoc.md. If the target generator includes "model_doc.mustache" and user passes "model-doc.mustache", this will result in duplicate docs being generated. We don't currently have a mechanism in place to inspect these.
See customization.md changes in this PR for full details. A quick example:
generatorName: kotlin
outputDir: samples/client/petstore/kotlin-user-customized-templates
inputSpec: modules/openapi-generator/src/test/resources/2_0/petstore.yaml
templateDir: .bak/kotlin-templates
library: jvm-okhttp3
additionalProperties:
artifactId: kotlin-petstore-client
serializableModel: "true"
dateLibrary: java8
files:
AUTHORS.md: {}
api_interfaces.mustache:
templateType: API
destinationFilename: Interface.kt
api.mustache:
templateType: API
destinationFilename: Impl.kt
Modifying bin/configs/kotlin.yaml
with the above, we can define the following files:
-
.bak/kotlin-templates/AUTHORS.md
(not included in the Kotlin generator) -
.bak/kotlin-templates/libraries/jvm-okhttp/api_interfaces.mustache
(not included in the Kotlin generator)
The above will generate an AUTHORS.md
, a user customized interface output for each API type generated, and will change the file suffix for the built-in api.mustache from .kt
to Impl.kt
.
Full output tree of the above config would look like this:
├── AUTHORS.md
├── README.md
├── build.gradle
├── docs
│ ├── ApiResponse.md
│ ├── Category.md
│ ├── Order.md
│ ├── Pet.md
│ ├── PetApi.md
│ ├── StoreApi.md
│ ├── Tag.md
│ ├── User.md
│ └── UserApi.md
├── settings.gradle
└── src
└── main
└── kotlin
└── org
└── openapitools
└── client
├── apis
│ ├── PetApiImpl.kt
│ ├── PetApiInterface.kt
│ ├── StoreApiImpl.kt
│ ├── StoreApiInterface.kt
│ ├── UserApiImpl.kt
│ └── UserApiInterface.kt
├── infrastructure
│ ├── ApiAbstractions.kt
│ ├── ApiClient.kt
│ ├── ApiInfrastructureResponse.kt
│ ├── ApplicationDelegates.kt
│ ├── ByteArrayAdapter.kt
│ ├── Errors.kt
│ ├── LocalDateAdapter.kt
│ ├── LocalDateTimeAdapter.kt
│ ├── OffsetDateTimeAdapter.kt
│ ├── RequestConfig.kt
│ ├── RequestMethod.kt
│ ├── ResponseExtensions.kt
│ ├── Serializer.kt
│ └── UUIDAdapter.kt
└── models
├── ApiResponse.kt
├── Category.kt
├── Order.kt
├── Pet.kt
├── Tag.kt
└── User.kt
10 directories, 39 files
Note the AUTHORS.md
and types/files under package org.openapitools.client.apis
.
cc @OpenAPITools/generator-core-team
Potential breaking change: This encapsulates properties of SupportingFiles. For users consuming programmatically via Java, this will require updating direct field accessors to getter/setters; Kotlin users consuming programmatically will be unaffected.
PR checklist
-
Read the contribution guidelines. -
Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community. -
If contributing template-only or documentation-only changes which will change sample output, build the project beforehand. -
Run the shell script ./bin/generate-samples.sh
to update all Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master. These must match the expectations made by your contribution. You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example./bin/generate-samples.sh bin/configs/java*
. For Windows users, please run the script in Git BASH. -
File the PR against the correct branch: master
-
Copy the technical committee to review the pull request if your PR is targeting a particular programming language.