diff --git a/.gitignore b/.gitignore index ef4f286cff..7e62d4fbd9 100644 --- a/.gitignore +++ b/.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/ diff --git a/docs/modules/ROOT/attachments/tekton/camel-k-pipeline-task-definition.yaml b/docs/modules/ROOT/attachments/tekton/camel-k-pipeline-task-definition.yaml index 220e434555..97b30e52ec 100644 --- a/docs/modules/ROOT/attachments/tekton/camel-k-pipeline-task-definition.yaml +++ b/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" diff --git a/docs/modules/ROOT/pages/configuration/build-time-properties.adoc b/docs/modules/ROOT/pages/configuration/build-time-properties.adoc index b8d239eb9e..3393e74c56 100644 --- a/docs/modules/ROOT/pages/configuration/build-time-properties.adoc +++ b/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. diff --git a/docs/modules/ROOT/pages/configuration/components.adoc b/docs/modules/ROOT/pages/configuration/components.adoc index ce95b99982..410c42c744 100644 --- a/docs/modules/ROOT/pages/configuration/components.adoc +++ b/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 ``` diff --git a/docs/modules/ROOT/pages/configuration/configuration.adoc b/docs/modules/ROOT/pages/configuration/configuration.adoc index febf7ef1a0..f44953f351 100644 --- a/docs/modules/ROOT/pages/configuration/configuration.adoc +++ b/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. diff --git a/docs/modules/ROOT/pages/configuration/maven-profile.adoc b/docs/modules/ROOT/pages/configuration/maven-profile.adoc index 3b6021a368..8bda1592e6 100644 --- a/docs/modules/ROOT/pages/configuration/maven-profile.adoc +++ b/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. diff --git a/docs/modules/ROOT/pages/configuration/runtime-config.adoc b/docs/modules/ROOT/pages/configuration/runtime-config.adoc index 2c616b9a8b..cce2072b35 100644 --- a/docs/modules/ROOT/pages/configuration/runtime-config.adoc +++ b/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. diff --git a/docs/modules/ROOT/pages/configuration/runtime-properties.adoc b/docs/modules/ROOT/pages/configuration/runtime-properties.adoc index 6ea9616400..f4fb39d759 100644 --- a/docs/modules/ROOT/pages/configuration/runtime-properties.adoc +++ b/docs/modules/ROOT/pages/configuration/runtime-properties.adoc @@ -8,17 +8,21 @@ During the execution of an `Integration` you can provide a single property or a Imagine you have a generic `Route` and you set a placeholder for certain information (ie, _my.message_ variable): -[source,groovy] -.property-route.groovy +[source,yaml] +.property-route.yaml ---- -from('timer:property') - .log('property content is: {{my.message}}') +- from: + uri: "timer:property" + steps: + - setBody: + simple: "property content is: {{my.message}}" + - to: "log:info" ---- The simplest way to replace that variable with a real value is to use the `--property` flag (also shortcut by `-p`): ---- -kamel run -p my.message=test-property property-route.groovy +kamel run -p my.message=test-property property-route.yaml ---- At runtime, that variable will be substituted by the value you've provided. You can provide more than one single `property` at once by just adding the flag repeatedly (ie, `--property prop1=val1 --property prop2=val2 ...`) @@ -26,17 +30,23 @@ At runtime, that variable will be substituted by the value you've provided. You You can also use runtime properties in Camel endpoints, for example to make the timer period configurable you can do as follows: -[source,groovy] -.property-route.groovy +[source,yaml] +.config-property-route.yaml ---- -from('timer:property?period={{triggerPeriod}}') - .log('property content is: {{my.message}}') +- from: + uri: "timer:property" + parameters: + period: "{{triggerPeriod}}" + steps: + - setBody: + simple: "property content is: {{my.message}}" + - to: "log:info" ---- The simplest way to replace that variable with a real value is to use the `--property` flag (also shortcut by `-p`): ---- -kamel run -p my.message=test-property -p triggerPeriod=3000 property-route.groovy +kamel run -p my.message=test-property -p triggerPeriod=3000 config-property-route.yaml ---- [[runtime-props-file]] @@ -45,24 +55,27 @@ kamel run -p my.message=test-property -p triggerPeriod=3000 property-route.groov Another way to provide more property configuration at once is to use a *property file*. [source,properties] -.my.properties +.config.properties ---- my.key.1=hello my.key.2=world ---- -[source,groovy] -.property-route.groovy +[source,yaml] +.config-property-file-route.yaml ---- -from('timer:property-file') - .routeId('property-file') - .log('property file content is: {{my.key.1}} {{my.key.2}}') +- from: + uri: "timer:property-file'" + steps: + - setBody: + simple: "property file content is: {{my.key.1}} {{my.key.2}}" + - to: "log:info" ---- You'll need to provide a `property` _file_ flag when launching the application: ---- -kamel run --property file:my.properties property-route.groovy +kamel run --property file:config.properties config-property-file-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. @@ -80,17 +93,23 @@ kubectl create configmap my-cm-rp --from-literal=name="Will Smith" --from-litera In our `Integration` we can simply refer to the properties defined in the `ConfigMap` as we'd do with any other property: -[source,groovy] -.property-configmap-route.groovy +[source,yaml] +.config-property-configmap-route.yaml ---- -from('timer:property?period={{period}}') - .log('Hello {{name}}!') +- from: + uri: "timer:property" + parameters: + period: "{{period}}" + steps: + - setBody: + simple: "Hello {{name}}!" + - to: "log:info" ---- Then we launch the `run` command with the `--property` flag whose value matches with the appropriate syntax to refer to `my-cm-rp`: ---- -kamel run --property configmap:my-cm-rp property-configmap-route.groovy +kamel run --property configmap:my-cm-rp config-property-configmap-route.yaml ---- The key-value pairs of the `ConfigMap` are loaded and used as runtime properties of the `Integration`. As soon as the application starts, you will see the log with the expected message. @@ -122,7 +141,7 @@ kubectl create configmap my-cm-rps --from-file=some.properties Then we launch the `run` command with the `--property` flag whose value matches with the appropriate syntax to refer to `my-cm-rps`: ---- -kamel run --property configmap:my-cm-rps property-configmap-route.groovy +kamel run --property configmap:my-cm-rps config-property-configmap-route.yaml ---- The value of the key-value of the `ConfigMap` is loaded as a property file and used as runtime properties of the `Integration`. As soon as the application starts, you will see the log with the expected message. diff --git a/docs/modules/ROOT/pages/configuration/runtime-resources.adoc b/docs/modules/ROOT/pages/configuration/runtime-resources.adoc index 1d43fcf828..a5aef8c923 100644 --- a/docs/modules/ROOT/pages/configuration/runtime-resources.adoc +++ b/docs/modules/ROOT/pages/configuration/runtime-resources.adoc @@ -20,17 +20,21 @@ kubectl create configmap my-cm --from-literal=my-configmap-key="configmap conten We want to use the materialized file in an integration: -[source,groovy] -.resource-configmap-route.groovy +[source,yaml] +.resource-configmap-route.yaml ---- -from('file:/etc/camel/resources/my-cm/?fileName=my-configmap-key&noop=true&idempotent=false') - .log('resource file content is: ${body}') +- from: + uri: "file:/etc/camel/resources/my-cm/?fileName=my-configmap-key&noop=true&idempotent=false" + steps: + - setBody: + simple: "resource file content is: ${body}" + - to: "log:info" ---- You can see that we're expecting to use a _my-configmap-key_ file stored in the default resource location (_/etc/camel/resources/_). In order to materialize the `Configmap` will be as easy as running the `--resource` _configmap_ syntax: ---- -kamel run --resource configmap:my-cm resource-configmap-route.groovy +kamel run --resource configmap:my-cm resource-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. @@ -50,17 +54,21 @@ 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] -.resource-secret-route.groovy +[source,yaml] +.resource-secret-route.yaml ---- -from('file:/etc/camel/resources/my-sec/?fileName=my-secret-key&noop=true&idempotent=false') - .log('resource file content is: ${body}') +- from: + uri: "file:/etc/camel/resources/my-sec/?fileName=my-secret-key&noop=true&idempotent=false" + steps: + - setBody: + simple: "secret file content is: ${body}" + - to: "log:info" ---- You can see that we're expecting to use a _my-secret-key_ file stored in the default resource location (_/etc/camel/resources/_). In order to materialize the `Secret` will be as easy as running the `--resource` _secret_ syntax: ---- -kamel run --resource secret:my-sec resource-secret-route.groovy +kamel run --resource secret:my-sec resource-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. @@ -78,20 +86,23 @@ As an example, let's create a `Configmap` named _my-cm_ containing certain infor kubectl create configmap my-cm-files --from-literal=input.txt="configmap input.txt content" ---- - Let's see an example where your integration expect a text file to be consumed under a specific filesystem location: -[source,groovy] -.resource-file-location-route.groovy +[source,yaml] +.resource-file-location-route.yaml ---- -from('file:/tmp/inputs/?fileName=input.txt&noop=true&idempotent=false') - .log('resource file content is: ${body}') +- from: + uri: "file:/tmp/inputs/?fileName=input.txt&noop=true&idempotent=false" + steps: + - setBody: + simple: "resource file content is: ${body}" + - to: "log:info" ---- When running the `Integration`, you can specify where to mount the resource content (either a `File`, `Configmap` or `Secret`) with the _@path_ syntax: ---- -kamel run --resource configmap:my-cm-files@/tmp/inputs resource-file-location-route.groovy +kamel run --resource configmap:my-cm-files@/tmp/inputs resource-file-location-route.yaml ---- You may check in the `Integration` `Pod` and verify that the file was mounted in the _tmp/inputs/input.txt_ destination. @@ -109,17 +120,21 @@ kubectl create configmap my-cm-multi --from-literal=my-configmap-key="configmap In our `Integration` we plan to use only one of the resources of the `Secret`: -[source,groovy] -.resource-configmap-key-location-route.groovy +[source,yaml] +.resource-configmap-key-location-route.yaml ---- -from('file:/tmp/app/data/?fileName=test.txt&noop=true&idempotent=false') - .log('resource file content is: ${body} consumed from ${header.CamelFileName}') +- from: + uri: "file:/tmp/app/data/?fileName=test.txt&noop=true&idempotent=false" + steps: + - setBody: + simple: "resource file content is: ${body} consumed from ${header.CamelFileName}" + - to: "log:info" ---- Let's use the _key_ filtering. Also notice that we're combining with the _@path_ syntax to declare where to mount the file: ---- -kamel run --resource configmap:my-cm-multi/my-configmap-key-2@/tmp/app/data/test.txt resource-configmap-key-location-route.groovy +kamel run --resource configmap:my-cm-multi/my-configmap-key-2@/tmp/app/data/test.txt resource-configmap-key-location-route.yaml ---- You may check in the `Integration` `Pod` that only the _test.txt_ file has been mounted under _/tmp/app/data_ directory containing the information you had in _my-configmap-key-2_.