extract versions to variable

Author: hauner

docs/modules/ROOT/pages/mapping/annotation.adoc

@@ -1,5 +1,6 @@
 = Annotation mapping
 include::partial$links.adoc[]
+include::partial$vars.adoc[]
 
 It is possible to add additional annotations to a `source type`. Currently, this is available as
 
@@ -100,9 +101,9 @@ Previously an annotation mapping was lost if the type was mapped at the same tim
 
 Assume the following mapping:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi-processor-mapping: v12
+openapi-processor-mapping: {var-mapping-version}
 
 options:
 
@@ -146,9 +147,9 @@ public class FooBar {
 
 Given the following OpenAPI description, that describe two (echo like) endpoints that receive an object via post and return the same object. In the mapping file we add a custom bean validation annotation. It checks the sum of both properties in `Foo` and `Bar`.
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi: 3.1.0
+openapi: {var-openapi-version}
 info:
   title: openapi-processor-spring sample api
   version: 1.0.0
@@ -217,9 +218,9 @@ components:
 
 and a `mapping.yaml` with annotation type mappings:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi-processor-mapping: v12 # <1>
+openapi-processor-mapping: {var-mapping-version} # <1>
 
 options:
   package-name: io.openapiprocessor.openapi

docs/modules/ROOT/pages/mapping/endpoint.adoc

@@ -1,5 +1,6 @@
 = Endpoint mappings
 include::partial$links.adoc[]
+include::partial$vars.adoc[]
 
 The global mapping variations are also available as explicit endpoint mappings. Instead of adding
 the mapping in the global sections `map/types`, `map/parameters` and `map/responses` they can
@@ -84,9 +85,9 @@ It is possible to add mappings that apply only to a specific http method. Motiva
 
 Here are a few examples of possible http endpoint mappings:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi-processor-mapping: v12
+openapi-processor-mapping: {var-mapping-version}
 
 map:
 

docs/modules/ROOT/pages/mapping/extension.adoc

@@ -1,5 +1,6 @@
 = Extension mapping
 include::partial$links.adoc[]
+include::partial$vars.adoc[]
 
 [.badge .badge-since]+since 2024.1+
 
@@ -9,8 +10,9 @@ Apart from the annotation mapping by an OpenAPI type, openapi-processor can use
 
 Here is a simple schema that has `x-` tensions on the `bar` property.
 
-```yaml
-openapi: 3.1.0
+[source,yaml,subs="attributes"]
+----
+openapi: {var-openapi-version}
 # ...
 components:
   schemas:
@@ -23,12 +25,13 @@ components:
           x-bar:
             - listA
             - listB
-```
+----
 
 In general openapi-processor will ignore the `x-` tension properties unless we map the `x-` tensions/values to annotations like this:
 
-```yaml
-openapi-processor-mapping: v12
+[source,yaml,subs="attributes"]
+----
+openapi-processor-mapping: {var-mapping-version}
 options:
   # ...
 
@@ -38,7 +41,7 @@ map:
     x-bar:
       - listA @ io.oap.FooB # <2>
       - listB @ io.oap.FooC
-```
+----
 
 NOTE: openapi-processor will only recognize *strings* values of an extension. It will ignore any other type.
 
@@ -50,7 +53,8 @@ The mapping allows two variations:
 
 With this mapping the generated Dto class will have the additional annotations on the property.
 
-```java
+[source,java]
+----
 package generated.model;
 
 import com.fasterxml.jackson.annotation.JsonProperty;
@@ -77,4 +81,4 @@ public class Foo {
     }
 
 }
-```
+----

docs/modules/ROOT/pages/mapping/global.adoc

@@ -1,12 +1,13 @@
 = Global mappings
+include::partial$vars.adoc[]
 
 Global type mapping will replace **any** usage of an OpenAPI type in the api description to the given java type.
 
 It is defined like below, and it should be added to the `map/types` section in the `mapping.yaml` which is a list of global type mappings:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi-processor-mapping: v12
+openapi-processor-mapping: {var-mapping-version}
 
 options:
   package-name: io.openapiprocessor.sample
@@ -143,9 +144,9 @@ This will generate the same code as the longer mapping version above.
 
 It is possible to create type mappings with nested generics types. Here are a few examples:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi-processor-mapping: v12
+openapi-processor-mapping: {var-mapping-version}
 
 options:
   package-name: generated

docs/modules/ROOT/pages/mapping/logging.adoc

@@ -1,4 +1,5 @@
 = log mapping lookup
+include::partial$vars.adoc[]
 
 It is possible to let a processor log all the mapping lookups. It *may* be useful to understand why a mapping does not work.
 
@@ -10,9 +11,9 @@ In case the processor uses the mapping, but it still doesn't behave as expected
 
 To control the logging there are two new xref:processor/configuration.adoc#_logging[logging options].
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi-processor-mapping: v12
+openapi-processor-mapping: {var-mapping-version}
 options:
   package-name: io.openapiprocessor.generated
 
@@ -99,9 +100,9 @@ If the `mapping-target` is `stdout` the processor output will be written without
 
 to enable logging with maven use:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi-processor-mapping: v12
+openapi-processor-mapping: {var-mapping-version}
 options:
   package-name: ...
 
@@ -115,9 +116,9 @@ logging:
 
 to get the simple output, or
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi-processor-mapping: v12
+openapi-processor-mapping: {var-mapping-version}
 options:
   package-name: ...
 
@@ -138,9 +139,9 @@ Gradle requires the `mapping-target` to be `stdout`. Gradle can only globally en
 
 to enable logging with gradle use:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi-processor-mapping: v12
+openapi-processor-mapping: {var-mapping-version}
 options:
   package-name: ...
 

docs/modules/ROOT/pages/mapping/null.adoc

@@ -1,3 +1,4 @@
+include::partial$vars.adoc[]
 :nullable: https://github.com/OpenAPITools/jackson-databind-nullable
 
 = Null mapping
@@ -30,9 +31,9 @@ Normally the processor would generate a simple pojo with a `String` property.
 
 By adding a `null` mapping for the `/foo` endpoint (this does work only on the endpoint level, a global null mapping gets ignored):
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi-processor-mapping: v12
+openapi-processor-mapping: {var-mapping-version}
 
 map:
   paths:

docs/modules/ROOT/pages/mapping/package-name.adoc

@@ -2,9 +2,9 @@
 
 The type mapping (v2 and up) configuration allows to reference the target `package-name` in generic parameters using the `+{package-name}+` expression. This makes it possible to adjust the `package-name` without touching the mapping, and it does reduce duplication.
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi-processor-mapping: v12
+openapi-processor-mapping: {var-mapping-version}
 options:
   package-name: io.openapiprocessor.generated
 

docs/modules/ROOT/pages/mapping/parameter.adoc

@@ -1,4 +1,5 @@
 = (global) Parameter mappings
+include::partial$vars.adoc[]
 
 Parameter mappings, as the name suggests, apply to the parameters of an endpoint method.
 
@@ -51,9 +52,9 @@ map:
 
 and an openapi.yaml with multiple endpoints having a parameter named "date"
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi: 3.0.2
+openapi: {var-openapi-version}
 info:
   title: global parameter type mapping example
   version: 1.0.0
@@ -107,9 +108,9 @@ It is possible to add additional parameters that is not described in the OpenAPI
 
 While it is possible to add it at the global level, it is best used at the endpoint level.
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi-processor-mapping: v12
+openapi-processor-mapping: {var-mapping-version}
 
 options:
   package-name: generated
@@ -123,9 +124,9 @@ map:
 
 Given the mapping configuration above and the following endpoint description:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi: 3.1.0
+openapi: {var-openapi-version}
 info:
   title: test additional endpoint parameter
   version: 1.0.0
@@ -174,9 +175,9 @@ It may also be useful to remove a parameter, maybe it is handled by a request fi
 
 Again, even if it is possible to add it at the global level, it is best used at the endpoint level.
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi-processor-mapping: v12
+openapi-processor-mapping: {var-mapping-version}
 
 options:
   package-name: generated
@@ -190,9 +191,9 @@ map:
 
 Given the configuration above and the following endpoint description:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi: 3.1.0
+openapi: {var-openapi-version}
 info:
   title: test unnecessary endpoint parameter
   version: 1.0.0

docs/modules/ROOT/pages/mapping/response.adoc

@@ -52,9 +52,9 @@ map:
 and an openapi.yaml with multiple endpoints returning their result as content type
 `application/vnd.something`
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi: 3.0.2
+openapi: {var-openapi-version}
 info:
   title: global response content type mapping example
   version: 1.0.0

docs/modules/ROOT/pages/mapping/schema.adoc

@@ -1,4 +1,5 @@
 = (global) Schema mappings
+include::partial$vars.adoc[]
 
 [.badge .badge-since]+since 2025.1+
 
@@ -19,9 +20,9 @@ The example will make this more clear.
 
 In the example OpenAPI below is a year value (<1>) that is used on the response schema and as query parameter.
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi: 3.1.0
+openapi: {var-openapi-version}
 info:
   title: schema mapping
   version: 1.0.0
@@ -59,9 +60,9 @@ components:
 
 Using a typical mapping the processor will use `java.time.Year` instead of a simple `Integer` type in the generated code.
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi-processor-mapping: v12
+openapi-processor-mapping: {var-mapping-version}
 
 options:
   package-name: generated
@@ -83,9 +84,9 @@ would change serialization of `java.time.Year` to a number.
 
 Adding the annotation mapping for this at the global type level
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi-processor-mapping: v12
+openapi-processor-mapping: {var-mapping-version}
 
 options:
   package-name: generated
@@ -143,9 +144,9 @@ but also at the method parameter of the generated interface:
 
 That is not wanted. To avoid it, the annotation mapping should be added to the new `schemas` mapping level:
 
-[source,yaml]
+[source,yaml,subs="attributes"]
 ----
-openapi-processor-mapping: v12
+openapi-processor-mapping: {var-mapping-version}
 
 options:
   package-name: generated