docs cleanup

Author: hauner

docs/index.md

@@ -4,7 +4,7 @@ title: Home
 nav_order: 1
 description: "Home Description"
 permalink: /
-date: 2020-02-16
+date: 2020-03-01
 ---
 
 <div style="display: flex; justify-content: flex-end; position: relative; top: 1.5em">
@@ -27,8 +27,9 @@ It is useful in an API first approach where you API is explicitly defined and do
  before it gets implemented. 
 
 The processor generates java interfaces based on the endpoint description of the API and simple POJO
-classes for parameter or response objects defined in th API. It is **your** task to create the controller
-classes that implement the interfaces. 
+classes for parameter or response objects defined in th API. The processor adds all the required
+spring & jackson annotations to the interface and all that is left to **you** is the implementation
+of the generated interfaces. 
 
 The interfaces will help to keep the implementation in sync with the API. If anything relevant changes
 in the API the interface changes and the compiler will warn that the interface is not implemented
@@ -37,10 +38,6 @@ correctly.
 See the [processor intro][docs-processor]{:target="_blank"} for a short example.
 {: .mb-6 }
 
-February 2020: The processor is ready to try but note that the it is still in an early state of
-development and may not generate the correct code yet in all cases. See [feedback](#feedback).
-{: .note .info .mb-6}
-
 
 ## table of contents
 {: .no_toc .text-delta }
@@ -72,22 +69,22 @@ See the [release notes][oaps-releases]{:target="_blank"}.
 - generates human readable code.
 
 - gradle support via [openapi-processor-gradle][oap-gradle] plugin (the plugin is currently the only option
- to run the generatr).
+ to run the processor).
 
 - add additional parameters to an endpoint which are not defined in the OpenAPI description. For example to pass
  a `HttpServletRequest` to the endpoint implementation. <span class="label label-green">since 1.0.0.M6</span>
 
 - supports bean validations. The constraints of the openapi description are mapped to java bean validation
  annotations. <span class="label label-green">since 1.0.0.M6</span>
 
-- allows to exclude endpoints from generation. This is useful if the generatr does not create the correct code for
- an endpoint. That way the generatr can still be used for all the other endpoints.
+- allows to exclude endpoints from generation. This is useful if the processor does not create the correct code for
+ an endpoint. That way the processor can still be used for all the other endpoints.
    <span class="label label-green">since 1.0.0.M6</span>
 
 - handle multiple responses by generating one endpoint method for each response content type.
-   <span class="label label-green">since 1.0.0.M8</span>
+   <span class="label label-green">since 1.0.0.M11</span>
 
-- <span class="label label-yellow">planned</span> WebFlux support, may need its own generatr. 
+- <span class="label label-yellow">planned</span> WebFlux support, may need its own processor. 
 
 - the generated code does not use swagger annotations. There is no need to generate the documentation from the code
   when the code is generated from the documentation (i.e. an openapi.yaml). 
@@ -99,10 +96,10 @@ with the [openapi-processor-gradle][oap-gradle] plugin. See [Using Gradle][docs-
 
 ## Feedback
 
-In case some feature is missing or the generated code is not 100% what you would expect create an [issue][oap-spring-issues]
+In case some feature is missing or the generated code is not 100% what you would expect create an [issue][oaps-issues]
 preferably with a test case. Providing a test case will help significantly :-) 
 
-A test case is a single folder with an openapi.yaml file and the expected Java files the generatr should create.
+A test case is a single folder with an openapi.yaml file and the expected Java files the processor should create.
 The structure looks like this:
 
     my-new-test-case/
@@ -136,12 +133,12 @@ openapi-processor-spring  is distributed by [Apache License 2.0][license].
 </ul>
 
 [badge-license]: https://img.shields.io/badge/License-Apache%202.0-blue.svg?labelColor=313A42
-[badge-ci]: https://github.com/hauner/openapi-generatr-spring/workflows/ci/badge.svg
+[badge-ci]: https://github.com/hauner/openapi-processor-spring/workflows/ci/badge.svg
 
-[workflow-ci]: https://github.com/hauner/openapi-generatr-spring/actions?query=workflow%3Aci
+[workflow-ci]: https://github.com/hauner/openapi-processor-spring/actions?query=workflow%3Aci
 
 [docs-gradle]: /openapi-processor-spring/gradle.html
-[docs-processor]: /openapi-processor-spring/generatr/
+[docs-processor]: /openapi-processor-spring/processor/
 [docs-mapping]: /openapi-gprocessor-spring/mapping/
 
 [bintray]: https://bintray.com/hauner/openapi-processor

docs/links.md

@@ -11,9 +11,11 @@ nav_order: 30
 - [OpenAPI tools][openapi-tools]{:target="_blank"}. List of OpenAPI tools.
 - "the" [OpenAPI generator][openapi-generator]{:target="_blank"}. Generate clients, servers and documentation from OpenAPI 2.0/3.x documents.
 - [Swagger OpenAPI parser][swagger-parser]. Java parser for OpenAPI specs.
+- [openapi4j OpenAPI parser][openapi4j]. Alternative Java parser for OpenAPI specs.
 
 [openapi]: https://www.openapis.org/
 [openapi-spec]: https://github.com/OAI/OpenAPI-Specification
 [openapi-generator]: https://openapi-generator.tech/
 [openapi-tools]: https://openapi.tools/
 [swagger-parser]: https://github.com/swagger-api/swagger-parser
+[openapi4j]: https://github.com/openapi4j/openapi4j

docs/mapping/basic.md

@@ -8,14 +8,14 @@ nav_order: 1
 # Basic (primitive) Mappings
 
 The OpenAPI specification defines a couple of basic [data types][openapi-spec-types]{:target="_blank"}.
-The basic data types are built-in into the generatr. That means the generatr will map the basic types
-automatically to a corresponding java type. There is no explicit type mapping required.
+The basic data types are built-in into the processor. That means it will map the basic types automatically
+ to a corresponding java type. There is no explicit type mapping required.
 
 ## OpenAPI to Java type mapping
 
 The following table shows the automatic mapping of OpenAPIs primitive types to Java.
 
-`type`    | `format`    | generatr Java type  
+`type`    | `format`    | processor Java type  
 ------    | --------    | ------------------  
 `integer` |             | `java.lang.Integer`          
 `integer` | `int32`     | `java.lang.Integer`          
@@ -28,7 +28,7 @@ The following table shows the automatic mapping of OpenAPIs primitive types to J
 `string`  | `binary`    | not (yet) implemented
 `boolean` |             | `java.lang.Boolean`
 `string`  | `date`      | `java.time.LocalDate`  
-`string`  | `date-time` | `java.time.OffsetDataTime` (since 1.0.0.A2)
+`string`  | `date-time` | `java.time.OffsetDataTime`
 `string`  | `password`  | ignored
 
 [openapi-spec-types]: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md#dataTypes

docs/mapping/global.md

@@ -53,7 +53,7 @@ can be mapped to an existing `Book` java type/class by the following mapping:
 
 ```yaml
 - from: Book
-  to: com.github.hauner.openapi.generatr.Book
+  to: com.github.hauner.openapi.oap.Book
 ```
 
 It is also possible to use a predefined OpenAPI type as the `from` type of a type mapping: 
@@ -63,17 +63,17 @@ It is also possible to use a predefined OpenAPI type as the `from` type of a typ
   to: java.util.List
 ```
 
-This tells the generatr to us a `java.util.List` instead of the OpenAPI type `array`.
+This tells the processor to us a `java.util.List` instead of the OpenAPI type `array`.
 
-The **generics** parameter is not required in this special case. The generatr knows `java.util.List`
+The **generics** parameter is not required in this special case. The processor knows `java.util.List`
 and will automatically use the `items` property of the `array` as the generic type.  
 
 <div markdown="1">
 **Important:**
-- OpenAPIs `object` type has no special handling if given as the `from` type. The generatr assumes
+- OpenAPIs `object` type has no special handling if given as the `from` type. The processor assumes
 that it is just a schema name and it will only match if there is schema with the name "object".   
 - global type mappings do not work on OpenAPI inline schemas. Inline schemas do not have a name so
-there is no way for the generatr to recognize it.
+there is no way for the processor to recognize it.
 </div>{: .note .important .mb-6}
 
 ## mapping basic (primitive) types with format
@@ -109,16 +109,16 @@ For example if a `StringPage` schema is defined in the OpenAPI that corresponds
     - java.lang.String
 ```
 
-The generatr will replace any use of `StringPage` with the **to** type and add the generic types
+The processor will replace any use of `StringPage` with the **to** type and add the generic types
  (in the given order) to the **to** type. 
 
-In case of the example above the generatr will create `Page<String>` instead of `StringPage` with an
+In case of the example above the processor will create `Page<String>` instead of `StringPage` with an
 additional `import` for the generic type (.. ignoring imports on `java.lang`).
 
 <div markdown="1">
 **Important:**
 
-The generatr does support only one level of generics. It is not possible to provide generic parameters
+The processor does support only one level of generics. It is not possible to provide generic parameters
 to generic parameters.
 </div>{: .note .important .mb-6}
 

docs/mapping/index.md

@@ -7,7 +7,7 @@ has_children: true
 
 # Type Mapping
 
-Using type mapping we can tell the generatr to map types (schemas) from an openapi.yaml description to
+Using type mapping we can tell the processor to map types (schemas) from an openapi.yaml description to
 a specific existing java type instead of generating a model class from the source OpenAPI type. 
 
 This can be a type created by us or a type from a framework. For example to map paging parameters and

docs/mapping/parameter.md

@@ -37,7 +37,7 @@ java type given by **to**.
 <div markdown="1">
 **Important:**
  
-Since the generatr will simply match the parameters by their name take care that all parameters of
+Since the processor will simply match the parameters by their name take care that all parameters of
 that name should really use the same type!
 </div>{: .note .important .mb-6}
 
@@ -100,7 +100,7 @@ and an openapi.yaml with multiple endpoints having a parameter named "date"
                         type: string
 ```
 
-the generatr will use `java.time.ZonedDateTime` as java type for **all** parameters named "date" in
+the processor will use `java.time.ZonedDateTime` as java type for **all** parameters named "date" in
 **all** endpoints that have a "date" parameter. 
 
 In the example both endpoints would use `java.time.ZonedDateTime` as java type for the "date" parameter.

docs/mapping/response.md

@@ -37,7 +37,7 @@ java type given by **to**.
 <div markdown="1">
 **Important:**
  
-Since the generatr will simply match the content type string take care that all responses of this
+Since the processor will simply match the content type string take care that all responses of this
 content type should really use the same type!
 
 This is probably only useful for vendor content types. Globally mapping the content type for example
@@ -89,5 +89,5 @@ and an openapi.yaml with multiple endpoints returning their result as content ty
  ```
 
 
-the generatr will use `com.github.hauner.openapi.Something` as java type for **all** responses with
+the processor will use `com.github.hauner.openapi.Something` as java type for **all** responses with
 the content type `application/vnd.something`.

docs/mapping/structure.md

@@ -52,4 +52,4 @@ the `map` key. The `map` key contains multiple sections to define the different
 
 ```
 
-[docs-configuration]: /openapi-generatr-spring/generatr/configuration.html
+[docs-configuration]: /openapi-processor-spring/processor/configuration.html

docs/processor/endpoints.md

@@ -60,7 +60,7 @@ A client request uses the request `Accept` header to tell the api which result c
 handle. 
 
 Using a single endpoint method it has to decide which response to create. This leads to some boring
-`if/else` code. To avoid this the generatr creates one endpoint method for each possible response.
+`if/else` code. To avoid this the processor creates one endpoint method for each possible response.
 
 For the example above it creates the following interface:
 

docs/processor/interfaces.md

@@ -37,7 +37,7 @@ The interface name used for this api will be `PingApi`. `Ping` because `ping` is
 
 In case no tags are given, all endpoints will be added to an `Api` interface.
 
-The package name gets created from the configurable `packageName` parameter of the generatr and a
+The package name gets created from the configurable `packageName` parameter of the processor and a
 sub package named `api`. 
 
 If the `packageName` is configured as `com.github.hauner.openapi` the final package name for the