|
1 | 1 | = Configuration
|
2 | 2 | include::partial$links.adoc[]
|
3 | 3 |
|
4 |
| -The processor reads the configuration from the (mandatory) `mapping.yaml` file. It does contain |
5 |
| -some general options and the xref:mapping/index.adoc[mapping] type information. |
| 4 | +The processor reads the configuration from the (mandatory) `mapping.yaml` file.It does contain |
| 5 | +some general options and the xref:mapping/index.adoc[mapping] type information. |
6 | 6 |
|
7 | 7 | A mapping yaml looks like this:
|
8 | 8 |
|
9 | 9 | [source,yaml]
|
10 | 10 | ----
|
| 11 | +openapi-processor-mapping: v2 |
| 12 | +
|
11 | 13 | options:
|
12 | 14 | package-name: io.openapiprocessor.sample
|
| 15 | + model-name-suffix: Resource |
13 | 16 | bean-validation: true
|
14 | 17 | javadoc: true
|
15 | 18 |
|
16 | 19 | map:
|
17 | 20 | # java type mappings
|
18 | 21 | ----
|
19 | 22 |
|
| 23 | +The only required option is `package-name`.All other options or the type mappings are optional. |
20 | 24 |
|
21 | 25 | == options:
|
22 | 26 |
|
23 |
| -* `package-name`: (**required**) the root package name of the generated interfaces & models. The |
24 |
| -package folder tree will be created inside the `targetDir` (see xref:gradle.adoc[using gradle]). |
| 27 | +* `package-name`: (**required**) the root package name of the generated interfaces & models.The |
| 28 | +package folder tree will be created inside the `targetDir` (see xref:gradle.adoc[using gradle]). |
25 | 29 | +
|
26 | 30 | Interfaces and models will be generated into the `api` and `model` subpackages of `package-name`.
|
27 | 31 | +
|
28 | 32 | ** so the final package name of the generated interfaces will be `"$\{package-name\}.api"`,
|
29 | 33 | ** and the final package name of the generated models will be `"$\{package-name\}.model"`
|
30 | 34 |
|
| 35 | +* `model-suffix-name` (**optional**, default is empty).See xref:_model_name_suffix[below]. |
| 36 | + |
31 | 37 | * `bean-validation` (**optional**, `true` or `false`) enables generation of bean validation
|
32 |
| -annotations. Default is `false`. See link:{bean-validation}[Bean Validation, window="_blank"]. |
| 38 | +annotations. Default is `false`. See link:{bean-validation}[Bean Validation Specification, window="_blank"]. |
| 39 | + |
| 40 | +* `javadoc` (**optional**, `true` or `false`) enables generation of JavaDoc comments from the OpenAPI `description` s on the API interfaces and model pojos.Default is `false`.This is still experimental. |
| 41 | + |
| 42 | +[#_model_name_suffix] |
| 43 | +=== `model-name-suffix` |
| 44 | + |
| 45 | +**optional** (string, default is empty (i.e. it is disabled)) |
| 46 | + |
| 47 | +The `model-name-suffix` option sets a suffix that is automatically appended to all generated model and enum classes. |
| 48 | + |
| 49 | +The suffix helps to |
| 50 | + |
| 51 | +* avoid duplicate class names in generated code and normal code |
| 52 | +* makes it easier to recognize which role or in which context a class is used. Is it a data transfer class or is it a domain class? |
| 53 | +* keeps the suffix "_noise_" out of the OpenAPI description |
| 54 | + |
| 55 | +Usually you will separate the classes by putting them in different packages. This helps to distinguish the classes, but when both are used in the same code, i.e. when converting one format to the other, it is a lot easier to distinguish them by their class name instead of their package name. |
| 56 | + |
| 57 | +If a schema name from the OpenAPI description already ends with the `model-name-suffix`, the processor will **not** append the suffix. This allows to migrate an existing api with a suffix in the API to `model-name-suffix` step by step. |
| 58 | + |
| 59 | +==== Example: |
| 60 | + |
| 61 | +*OpenAPI* |
| 62 | +[source,yaml] |
| 63 | +---- |
| 64 | +paths: |
| 65 | + /foo: |
| 66 | + get: |
| 67 | + responses: |
| 68 | + '200': |
| 69 | + description: the foo result |
| 70 | + content: |
| 71 | + application/json: |
| 72 | + schema: |
| 73 | + $ref: '#/components/schemas/Foo' # <1> |
| 74 | +
|
| 75 | +components: |
| 76 | + schemas: |
| 77 | +
|
| 78 | + Foo: |
| 79 | + type: object |
| 80 | + properties: |
| 81 | + nested: |
| 82 | + $ref: '#/components/schemas/BarResource' # <1> |
| 83 | +
|
| 84 | + BarResource: |
| 85 | + type: object |
| 86 | + properties: |
| 87 | + prop: |
| 88 | + type: string |
| 89 | +---- |
| 90 | + |
| 91 | +*mapping.yaml* |
| 92 | +[source,yaml] |
| 93 | +---- |
| 94 | +openapi-processor-mapping: v2 |
| 95 | +
|
| 96 | +options: |
| 97 | + package-name: io.openapiprocessor.sample |
| 98 | + model-name-suffix: Resource # <2> |
| 99 | +---- |
| 100 | + |
| 101 | +*Java* |
| 102 | +[source,java] |
| 103 | +---- |
| 104 | +// interface |
| 105 | +public interface Api { |
| 106 | +
|
| 107 | + @Mapping("/foo") |
| 108 | + FooResource getFoo(); // <3> |
| 109 | +
|
| 110 | +} |
| 111 | +
|
| 112 | +// pojos |
| 113 | +public class FooResource { // <3> |
| 114 | +
|
| 115 | + // ... |
| 116 | +
|
| 117 | + @JsonProperty("nested") |
| 118 | + private BarResource nested; |
| 119 | +
|
| 120 | + // ... |
| 121 | +} |
| 122 | +
|
| 123 | +public class BarResource { // <4> |
| 124 | +
|
| 125 | + // ... |
| 126 | +} |
| 127 | +---- |
33 | 128 |
|
34 |
| -* `javadoc` (**optional**, `true` or `false`) enables generation of JavaDoc comments from the OpenAPI `description` s on the API interfaces and model pojos. Default is `false`. This is still experimental. |
| 129 | +<1> a schema name without suffix |
| 130 | +<2> the suffix configuration |
| 131 | +<3> the class name of the `Foo` schema got the configured `Resource` suffix |
| 132 | +<4> the class name of the `BarResource` is identical to the original schema name. Since the existing suffix is equal to `model-name-suffix` it is ignored. Otherwise, This prevents funny class names like `BarResourceResource`. |
35 | 133 |
|
36 | 134 | == map:
|
37 | 135 |
|
|
0 commit comments