renamed project in docs

Author: hauner

docs/Gemfile.lock

@@ -16,7 +16,7 @@ GEM
     colorator (1.1.0)
     commonmarker (0.17.13)
       ruby-enum (~> 0.5)
-    concurrent-ruby (1.1.5)
+    concurrent-ruby (1.1.6)
     dnsruby (1.61.3)
       addressable (~> 2.5)
     em-websocket (0.5.1)
@@ -204,9 +204,9 @@ GEM
       jekyll-seo-tag (~> 2.1)
     minitest (5.14.0)
     multipart-post (2.1.1)
-    nokogiri (1.10.7)
+    nokogiri (1.10.8)
       mini_portile2 (~> 2.4.0)
-    octokit (4.15.0)
+    octokit (4.16.0)
       faraday (>= 0.9)
       sawyer (~> 0.8.0, >= 0.5.3)
     pathutil (0.16.2)

docs/_config.yml

@@ -1,10 +1,10 @@
-title: openapi-generatr-spring
+title: openapi-processor-spring
 
 description: >-
-  an openapi generatr for spring-boot
+  an openapi-processor for spring-boot
 
 url: "https://hauner.github.io"
-baseurl: "/openapi-generatr-spring/"
+baseurl: "/openapi-processor-spring"
 
 twitter_username: "@MartinHauner"
 github_username:  hauner
@@ -17,14 +17,20 @@ exclude:
   - api.md
   - gradle-obsolete.md
 
+include:
+  - ../images
+
 ##
 ## "just-the-docs" theme options
 ##
 search_enabled: true
 search_tokenizer_separator: /[\s/]+/
 
+# logo, replaces the title
+logo: "../images/openapi-processor-spring@1280x200.png"
+
 aux_links:
-  openapi-generatr-spring:
-    - //github.com/hauner/openapi-generatr-spring
+  openapi-processor-spring:
+    - //github.com/hauner/openapi-processor-spring
 
 #footer_content:

docs/api.md

@@ -1,6 +1,6 @@
 ---
 layout: default
-title: Generatr API
+title: Processor API
 nav_order: 20
 ---
 
@@ -10,7 +10,7 @@ nav_order: 20
 todo
 {: .label .label-yellow }
 
-describe the generatr api
+describe the processor api
 
 ## table of contents
 {: .no_toc .text-delta }

docs/gradle-obsolete.md

@@ -7,16 +7,17 @@ nav_order: 9
 # Using Gradle
 {: .no_toc }
 
-Note: this page is for the gradle plugin since version '1.0.0.M5'. The new plugin provides proper
-up-to-date checking (it does not re-run the generatr when the api yaml is unchanged) and uses a
+Note: this page is for the gradle plugin since version '1.0.0.M6'. The new plugin provides proper
+up-to-date checking (it does not re-run the processor when the api yaml is unchanged) and uses a
 simpler configuration.
 {: .note .info .mb-6}
 
 
-The [openapi-generatr-gradle][generatr-gradle] is currently the only way to run a **openapi-generatr.** 
+The [openapi-processor-gradle][oap-gradle] is currently the only tool to run a **openapi-processor**. 
 
 To use it in a gradle project the gradle file of the project requires a few additional instructions.
-The following sections describe how to activate & configure **generatr-spring** in a `build.gradle` file. 
+The following sections describe how to activate & configure **openapi-processor-spring** in a
+`build.gradle` file. 
 {: .mb-6 }
 
 ## table of contents
@@ -28,26 +29,26 @@ The following sections describe how to activate & configure **generatr-spring**
 
 # adding the plugin
 
-The [openapi-generatr-gradle][generatr-gradle] plugin is activated (like any other gradle plugin) in
+The [openapi-processor-gradle][oap-gradle] plugin is activated (like any other gradle plugin) in
  the `plugins` configuration: 
 
         plugins {
             ....
-            // add generatr-gradle plugin
-            id 'com.github.hauner.openapi-generatr' version '<version>'
+            // add openapi-processor-gradle plugin
+            id 'com.github.hauner.openapi-processor' version '<version>'
         }
         
         
-# configuring generatr-spring
+# configuring openapi-processor-spring
 
-The plugin will add an `openapiGeneratr` configuration block that is used to configure the generatrs.
-Configuration for a specific generatr is placed inside it using the generatr name as configuration
+The plugin will add an `openapiProcessor` configuration block that is used to configure the processors.
+Configuration for a specific processor is placed inside it using the processor name as configuration
 block name.   
 
-        openapiGeneratr {
+        openapiProcessor {
 
             spring {
-                generatr 'com.github.hauner.openapi:openapi-generatr-spring:<version>'
+                processor 'com.github.hauner.openapi:openapi-processor-spring:<version>'
                 apiPath "$projectDir/src/api/openapi.yaml"
                 targetDir "$projectDir/build/openapi"
                 mapping "$projectDir/openapi-mapping.yaml"
@@ -56,20 +57,20 @@ block name.
 
         }
 
-- `generatr`: (**required**) the generatr dependency. This works in the same way as adding a dependency
+- `processor`: (**required**) the generatr dependency. This works in the same way as adding a dependency
  to a configuration in the gradle `dependencies` block. It is given here to avoid un-wanted side effects
   on the build dependencies of the project.
 
-- `apiPath`: (**required**) the path to the `openapi.yaml` file and the main input for the generatr. If
-set in the top level block it will be used for all configured generatrs.
+- `apiPath`: (**required**) the path to the `openapi.yaml` file and the main input for the processor. If
+set in the top level block it will be used for all configured processors.
 
 - `targetDir`: (**required**) the output folder for generating interfaces & models. This is the parent
  of the `packageName` folder tree. It is recommended to set this to a subfolder of gradle's standard `build`
 directory so it is cleared by the `clean` task and does not pollute the sources directory.
 
-  See [running the generatr][docs-running] how to include the `targetDir` in compilation & packing.  
+  See [running the processor][docs-running] how to include the `targetDir` in compilation & packing.  
 
-- `mapping`: (**required**, since 1.0.0.M6) provides the generatr mapping options. This is a path
+- `mapping`: (**required**, since 1.0.0.M6) provides the processor mapping options. This is a path
  to yaml file. See [Configuration][docs-configuration] for a description of the mapping yaml. This replaces
  the `typeMappings` option. 
 
@@ -100,13 +101,13 @@ directory so it is cleared by the `clean` task and does not pollute the sources
   [Configuration][docs-configuration].
   {: .mb-5 }
 
-# running generatr-spring
+# running processor-spring
 
-The plugin will add a gradle task `generateSpring` to run the generatr. 
+The plugin will add a gradle task `processSpring` to run the processor. 
 
-To automatically generate & compile the generatr output two additional configurations are required.
+To automatically generate & compile the processor output two additional configurations are required.
 
-- the `sourceSets` are extended to include the generatr output (assuming a java project):
+- the `sourceSets` are extended to include the processor output (assuming a java project):
 
         sourceSets {
             main {
@@ -118,17 +119,17 @@ To automatically generate & compile the generatr output two additional configura
         }
 
 
- - and the `compileJava` task gets a dependency on `generateSpring` so it runs before compilation (again,
+ - and the `compileJava` task gets a dependency on `processSpring` so it runs before compilation (again,
   assuming a java project):  
 
         // generate api before compiling
-        compileJava.dependsOn ('generateSpring')
+        compileJava.dependsOn ('processSpring')
 
 Adding automatic compilation in this way will also automatically include the generated files into the
 `jar` build artifact. 
 
 
-[generatr-gradle]: https://github.com/hauner/openapi-generatr-gradle
-[docs-mapping]: /openapi-generatr-spring/mapping/
-[docs-configuration]: /openapi-generatr-spring/generatr/configuration.html
-[docs-running]: #running-generatr-spring
+[oap-gradle]: https://github.com/hauner/openapi-processor-gradle
+[docs-mapping]: /openapi-processor-spring/mapping/
+[docs-configuration]: /openapi-processor-spring/generatr/configuration.html
+[docs-running]: #running-processor-spring

docs/gradle.md

@@ -5,7 +5,7 @@ parent: HowTo's
 nav_order: 1
 ---
 
-# generatr: map openapi array (globally) to a java collection type 
+# processor: map openapi array (globally) to a java collection type 
 
 By default the OpenAPI `array` is mapped to a simple java array. It is possible to change that default 
 mapping for example to `java.util.Collection` by adding a type mapping to the [`mapping.yaml`][docs-mapping].
@@ -28,7 +28,7 @@ Given the following openapi.yaml fragment:
                       type: string
 ```
 
-the generatr will create the following endpoint interface:
+the processor will create the following endpoint interface:
 
 ```java
     @GetMapping(path = "/array", produces = {"application/json"});
@@ -56,13 +56,13 @@ will change the generated endpoint to:
 
 using the `array`s `items` property as the generic parameter of `Collection`.
 
-The generatr needs to know the given collection type to generate proper java code so we can't simply
-add a random collection type. The generatr does currently recognize the following types:
+The processor needs to know the given collection type to generate proper java code so we can't simply
+add a random collection type. The processor does currently recognize the following types:
 
 - `java.util.Collection`
 - `java.util.List`
 - `java.util.Set`
 
 
 
-[docs-mapping]: /openapi-generatr-spring/mapping/
+[docs-mapping]: /openapi-processor-spring/mapping/

docs/howto/global-array-mapping.md

@@ -7,4 +7,4 @@ has_children: true
 
 # HowTo's
 
-This section collects some small examples how to configure the generatr to achieve the expected output. 
+This section collects some small examples how to configure the processor to achieve the expected output. 

docs/howto/index.md

@@ -5,7 +5,7 @@ parent: HowTo's
 nav_order: 5
 ---
 
-# generatr: using Spring Pageable & Page 
+# processor: using Spring Pageable & Page 
 
 The given (lengthy) openapi yaml example describes a pageable api in two variations. The `/page`
 endpoint uses named objects and the second endpoint `/page-inline` uses inline objects to describe
@@ -111,7 +111,7 @@ components:
         - $ref: '#/components/schemas/StringContent'
 ```
 
-The generatr does create a proper interface with both endpoints if we provide a type mappings for the
+The processor does create a proper interface with both endpoints if we provide a type mappings for the
 `Pageable` and `Page` types. 
 
 Here is the java code we expect:
@@ -168,5 +168,5 @@ Usually you would use the first variation using named objects so they can be re-
 In that case you will only need the global type mapping of `Pageable` and the `StringPage`. Note that
 the `StringPage` uses a generic parameter.
 
-Worth mentioning is that the generatr will not generate model classes for the openapi types `Pageable`,
+Worth mentioning is that the processor will not generate model classes for the openapi types `Pageable`,
 `Page`, `StringContent` or `StringPage`.