diff --git a/README.md b/README.md index 7ab57b62..3cc95237 100644 --- a/README.md +++ b/README.md @@ -23,7 +23,7 @@ Another example for such a module is: ## Documentation JavaDoc is being used throughout the codebase, offering contextual information in your respective IDE or being available online through services like [javadoc.io](https://www.javadoc.io/doc/com.github.victools/jsonschema-generator). -Additional documentation can be found here: (https://victools.github.io/jsonschema-generator/) +Additional documentation and configuration examples can be found here: https://victools.github.io/jsonschema-generator ---- diff --git a/slate-docs/source/includes/_faq.md b/slate-docs/source/includes/_faq.md index 3090a025..66237f08 100644 --- a/slate-docs/source/includes/_faq.md +++ b/slate-docs/source/includes/_faq.md @@ -68,7 +68,7 @@ Enums are a special construct for which there are multiple options: 5. Write your own custom definition provider or re-use the `EnumModule` class as in the shown example. ## Where can I find some more configuration examples? -Internally, a number of the standard `Option`s are realized via [Individual Configurations](#individual-configurations) and/or [Advanced Configurations](#advanced-configurations) – grouped into `Module`s. +Internally, a number of the standard `Option`s are realized via [Individual Configurations](#generator-individual-configurations) and/or [Advanced Configurations](#generator-advanced-configurations) – grouped into `Module`s. These make for excellent [examples](https://github.com/victools/jsonschema-generator/tree/master/jsonschema-generator/src/main/java/com/github/victools/jsonschema/generator/impl/module) to get you started into your own setup, if the existing `Option`s do not cover your specific requirements. ## How to represent a `Map` in a generated schema? @@ -129,7 +129,7 @@ configBuilder.forFields().withDefaultResolver(field -> { }); ``` -The short answer is: via the `withDefaultResolver()` – one of the [Individual Configurations](#13-individual-configurations). +The short answer is: via the `withDefaultResolver()` – one of the [Individual Configurations](#generator-individual-configurations). The exact details depend on how the `default` value can be determined. 1. If the `default` value is explicitly stated via some kind of annotation, it might be as simple as "Example 1" on the right. diff --git a/slate-docs/source/includes/_maven-plugin.md b/slate-docs/source/includes/_maven-plugin.md index cb7ea8f4..b1520f9b 100644 --- a/slate-docs/source/includes/_maven-plugin.md +++ b/slate-docs/source/includes/_maven-plugin.md @@ -44,7 +44,7 @@ There are some additional parameters available in the plugin ``: ``` -The standard generator [`Option`s](#configuration-through-options) can be included via the `` tag. +The standard generator [`Option`s](#generator-options) can be included via the `` tag. ## Further configurations through Modules ```xml diff --git a/slate-docs/source/includes/_motivation.md b/slate-docs/source/includes/_motivation.md index c65a51da..43b13c29 100644 --- a/slate-docs/source/includes/_motivation.md +++ b/slate-docs/source/includes/_motivation.md @@ -13,7 +13,7 @@ of building custom applications for each customer. That means, such a product ne for every customer. Amongst other things, we do this through heaps of configuration options. In order to achieve the desired flexibility, these configurations are sometimes very technical. E.g. allowing our customers (i.e. users) to define JavaScript expressions based on our own Java DOM. In reality this means quite often: customers can configure it -themselves but will still ask us/me to provide those expression. However, that poses the challenge of documenting our +themselves but will still ask us/me to provide those expressions. However, that poses the challenge of documenting our DOM in a way that it can be used without having access to the code itself or its JavaDoc. I couldn't find a nice way of doing the above without sentencing myself to constantly maintain a huge amount of documentation. @@ -26,7 +26,7 @@ While I had already spent considerable amounts of my spare time on this frontend – I really missed the strong Java typing!), I realized that the existing JSON Schema generation libraries typically expected some specific annotations throughout the code base for the sole purpose of generating a JSON Schema. I surely wasn't expecting our developers to go through hundreds of classes and specifying schema parts (by this time Draft -version 7) throughout the codebase. And none of the existing generation library seemed to allow for methods to be +version 7) throughout the codebase. And none of the existing generation libraries seemed to allow for methods to be documented (understandable, if you only aim at documenting a JSON structure, but not good enough for my purposes after all).