(#5489) Yaml - docs configuration

.gitignore

@@ -38,6 +38,7 @@ index.Dockerfile
 .gopath
 
 # Temporary Build Files
+/api_*
 build/_output
 build/_offline
 build/camel-k-runtime-*-maven-offline.tar.gz
@@ -49,7 +50,7 @@ build/_maven_overlay/
 build/maven/target/
 build/maven
 build/m2
-/api_*
+_scratch/
 
 # YAKS test output
 .yaks-jbang/

docs/modules/ROOT/attachments/tekton/camel-k-pipeline-task-definition.yaml

@@ -87,4 +87,4 @@ spec:
             resource: source-repo
       params:
         - name: file
-          value: "examples/tekton/hello.groovy"
+          value: "examples/tekton/hello.yaml"

docs/modules/ROOT/pages/configuration/build-time-properties.adoc

@@ -8,17 +8,21 @@ You may be required to provide certain *build-time properties* that are needed o
 
 You will find this feature very useful when dealing with configuration that affects how `Quarkus` builds the `Integration`. For example, let's see how to override the default `quarkus.application.name` expected by any `Quarkus` application:
 
-[source,groovy]
-.build-property-route.groovy
+[source,yaml]
+.build-property-route.yaml
 ----
-from('timer:build-property')
-    .log('The application name: {{quarkus.application.name}}')
+- from:
+    uri: "timer:build-property"
+    steps:
+      - setBody:
+          simple: "The application name: {{quarkus.application.name}}"
+      - to: "log:info"
 ----
 
 In order to give a value to the `quarkus.application.name` property you can pass it using the command line with the `--build-property` flag:
 
 ----
-kamel run --build-property=quarkus.application.name=my-super-application build-property-route.groovy
+kamel run --build-property=quarkus.application.name=my-super-application build-property-route.yaml
 ----
 
 You can provide more than one single `build-property` at once by just adding the flag repeatedly (ie, `--build-property=prop1=val1 --build-property=prop2=val2 ...`)
@@ -35,17 +39,21 @@ quarkus.application.name = my-super-application
 quarkus.banner.enabled = true
 ----
 
-[source,groovy]
-.build-property-route.groovy
+[source,yaml]
+.build-property-route.yaml
 ----
-from('timer:build-property')
-    .log('The application name: {{quarkus.application.name}}')
+- from:
+    uri: "timer:build-property"
+    steps:
+      - setBody:
+          simple: "The application name: {{quarkus.application.name}}"
+      - to: "log:info"
 ----
 
 The `quarkus.banner.enabled` is configured to show the banner during the `Integration` startup. Let's use `--build-property` flag in conjunction with file:
 
 ----
-kamel run --build-property=file:quarkus.properties build-property-route.groovy
+kamel run --build-property=file:quarkus.properties build-property-route.yaml
 ----
 
 The property file is parsed and its properties configured on the `Integration`. As soon as the application starts, you will see the log with the expected configuration.
@@ -63,17 +71,21 @@ kubectl create configmap my-cm-bp --from-literal=quarkus.application.name="my-gr
 
 Here, as an example we have create a configmap with 2 `Quarkus` properties.
 
-[source,groovy]
-.build-property-route.groovy
+[source,yaml]
+.build-property-route.yaml
 ----
-from('timer:build-property')
-    .log('The application name: {{quarkus.application.name}}')
+- from:
+    uri: "timer:build-property"
+    steps:
+      - setBody:
+          simple: "The application name: {{quarkus.application.name}}"
+      - to: "log:info"
 ----
 
 The `quarkus.banner.enabled` is configured to show the banner during the `Integration` startup. Let's use `--build-property` flag in conjunction with file:
 
 ----
-kamel run --build-property=configmap:my-cm-bp build-property-route.groovy
+kamel run --build-property=configmap:my-cm-bp build-property-route.yaml
 ----
 
 The key-value pairs of the `ConfigMap` are loaded and used as build-time properties of the `Integration`. As soon as the application starts, you will see the log with the expected configuration.
@@ -105,7 +117,7 @@ kubectl create configmap my-cm-bps --from-file=quarkus.properties
 Then we launch the `run` command with the `--build-property` flag whose value matches with the appropriate syntax to refer to `my-cm-bps`:
 
 ----
-kamel run --build-property configmap:my-cm-bps build-property-route.groovy
+kamel run --build-property configmap:my-cm-bps build-property-route.yaml
 ----
 
 The value of the key-value of the `ConfigMap` is loaded as a property file and used as build-time properties of the `Integration`. you will see the log with the expected configuration.

docs/modules/ROOT/pages/configuration/components.adoc

@@ -2,19 +2,36 @@
 
 Camel components can be configured programmatically (within the integration code) or using properties with the following syntax:
 
-```
+[source]
+----
 camel.component.${scheme}.${property}=${value}
-```
+----
 
 As example if you want to change the queue size of the seda component, you can use the following property:
 
-```
+[source]
+----
 camel.component.seda.queueSize=10
-```
+----
 
 For example, you can do it when running the integration from the command line:
 
+[source,yaml]
+.config-seda-route.yaml
+----
+- from:
+    uri: "timer:seda"
+    steps:
+      - setBody:
+          simple: "Hello World!"
+      - to: "seda:next"
+- from:
+    uri: "seda:next"
+    steps:
+      - to: "log:info"
+----
+
 ```
-kamel run --property camel.component.seda.queueSize=10 examples/routes.groovy
+kamel run --property camel.component.seda.queueSize=10 config-seda-route.yaml
 ```
 

docs/modules/ROOT/pages/configuration/configuration.adoc

@@ -7,17 +7,22 @@ The property value can be used inside Camel K integrations using the *property p
 
 The syntax for properties has the form `{{my.property}}`, for example:
 
-[source,groovy]
-.props.groovy
+[source,yaml]
+.property-route.yaml
 ----
-from('timer:props?period=1000')
-    .log('{{my.message}}')
+- from:
+    uri: "timer:props"
+    steps:
+      - setBody:
+          simple: "{{my.message}}"
+      - to: "log:info"
 ----
 
 In order to give a value to the `my.message` property you can pass it using the command line:
 
-```
-kamel run --property my.message="Hello World" props.groovy
-```
+[source]
+----
+kamel run --property my.message="Hello World" property-route.yaml
+----
 
 For more details and advanced use cases, see the xref:configuration/runtime-properties.adoc[runtime properties] section.

docs/modules/ROOT/pages/configuration/maven-profile.adoc

@@ -19,7 +19,7 @@ kubectl create cm my-maven-profile --from-file my-profile.xml
 Once the Configmap/Secret is ready, then, you can use it to run your integration:
 
 ```
-kamel run hello.groovy -t builder.maven-profile=configmap:my-maven-profile/my-profile.xml
+kamel run hello.yaml -t builder.maven-profile=configmap:my-maven-profile/my-profile.xml
 ```
 
 The profile will be added to your integration's project generated pom file. What will be changed in the `mvn package` execution will depend on your profile definition.

docs/modules/ROOT/pages/configuration/runtime-config.adoc

@@ -20,19 +20,23 @@ kubectl create configmap my-cm --from-literal=my-configmap-key="configmap conten
 
 We want to use the materialized file in an integration:
 
-[source,groovy]
-.config-configmap-route.groovy
+[source,yaml]
+.config-configmap-route.yaml
 ----
-from('timer:configmap')
-    .setBody()
-        .simple("resource:classpath:my-configmap-key")
-    .log('configmap content is: ${body}')
+- from:
+    uri: "timer:configmap"
+    steps:
+      - setBody:
+          simple: "resource:classpath:my-configmap-key"
+      - setBody:
+          simple: "configmap content is: ${body}"
+      - to: "log:info"
 ----
 
 You can see that we're expecting to use a _my-configmap-key_ file stored somewhere in the classpath. In order to materialize the `Configmap` will be as easy as running the `--config` _configmap_ syntax:
 
 ----
-kamel run --config configmap:my-cm config-configmap-route.groovy
+kamel run --config configmap:my-cm config-configmap-route.yaml
 ----
 
 As soon as the `Integration` starts, the `Camel K` operator will take care to mount a volume with the `Configmap` 's content.
@@ -52,19 +56,23 @@ kubectl create secret generic my-sec --from-literal=my-secret-key="very top secr
 
 We want to use the materialized secret file in an integration:
 
-[source,groovy]
-.config-secret-route.groovy
+[source,yaml]
+.config-secret-route.yaml
 ----
-from('timer:secret')
-    .setBody()
-        .simple("resource:classpath:my-secret-key")
-    .log('secret content is: ${body}')
+- from:
+    uri: "timer:secret"
+    steps:
+      - setBody:
+          simple: "resource:classpath:my-secret-key"
+      - setBody:
+          simple: "secret content is: ${body}"
+      - to: "log:info"
 ----
 
 You can see that we're expecting to use a _my-secret-key_ file stored somewhere in the classpath. In order to materialize the `Secret` will be as easy as running the `--config` _secret_ syntax:
 
 ----
-kamel run --config secret:my-sec config-secret-route.groovy
+kamel run --config secret:my-sec config-secret-route.yaml
 ----
 
 As soon as the `Integration` starts, the `Camel K` operator will take care to mount a volume with the `Secret` 's content.
@@ -77,29 +85,33 @@ NOTE: you can provide a `Secret` which is not yet available on the cluster. The
 Each `Configmap`/`Secret` will be parsed as a property file and you will be able to use those properties inside your `Route` definition or, more in general, as you would do with any other xref:configuration/runtime-properties.adoc[runtime property]. As an example, you can create the following `Secret`:
 
 [source,text]
-.my.properties
+.secret.properties
 ----
 my.key.1=hello
 my.key.2=world
 ----
+
 ----
-kubectl create secret generic my-secret-properties --from-file=my.properties
+kubectl create secret generic my-secret-properties --from-file=secret.properties
 ----
 
 In our `Integration` we can simply refer the properties defined in the `Secret` as we would do with any other property:
 
-[source,groovy]
-.config-secret-property-route.groovy
+[source,yaml]
+.config-secret-property-route.yaml
 ----
-from('timer:secret')
-    .routeId('secret')
-    .log('{{my.key.1}} {{my.key.2}}')
+- from:
+    uri: "timer:secret"
+    steps:
+      - setBody:
+          simple: "{{my.key.1}} {{my.key.2}}"
+      - to: "log:info"
 ----
 
 We just have to provide the `--config` we are willing to use:
 
 ----
-kamel run --config secret:my-secret-properties config-secret-property-route.groovy
+kamel run --config secret:my-secret-properties config-secret-property-route.yaml
 ----
 
 [[runtime-config-keys]]
@@ -115,19 +127,23 @@ kubectl create secret generic my-sec-multi --from-literal=my-secret-key="very to
 
 In our `Integration` we plan to use only one of the resources of the `Secret`:
 
-[source,groovy]
-.config-secret-key-route.groovy
+[source,yaml]
+.config-secret-key-route.yaml
 ----
-from('timer:secret')
-    .setBody()
-        .simple("resource:classpath:my-secret-key-2")
-    .log('secret content is: ${body}')
+- from:
+    uri: "timer:secret"
+    steps:
+      - setBody:
+          simple: "resource:classpath:my-secret-key-2"
+      - setBody:
+          simple: "secret content is: ${body}"
+      - to: "log:info"
 ----
 
 Let's use the _key_ filtering:
 
 ----
-kamel run --config secret:my-sec-multi/my-secret-key-2 config-secret-key-route.groovy
+kamel run --config secret:my-sec-multi/my-secret-key-2 config-secret-key-route.yaml
 ----
 
 You may check in the `Integration` `Pod` that only the _my-secret-key-2_ data has been mounted.