Build time properties

You may be required to provide certain build-time properties that are needed only during the process of Integration building. Since Camel K version 1.5, we introduced a --build-property flag that will be handful in such circumstances. The property value may be also used inside Camel K integrations using the property placeholder mechanism.

Single property

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:

build-property-route.yaml
- 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.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 …​)

Property File

Repeating the --build-property flag when you have many build time configuration may be cumbersome. Usually you deal with property files instead. You will be able to use the file syntax available for --build-property flag. Here, as an example you have a property file with 2 Quarkus properties:

quarkus.properties
quarkus.application.name = my-super-application
quarkus.banner.enabled = true
build-property-route.yaml
- 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.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.

Property from ConfigMap/Secret

In case some build-time properties are stored into a Configmap or a Secret, you can use the --build-property flag with a value of type respectively configmap:name-of-configmap or secret:name-of-secret to refer to the specific resource to use as build-time properties.

As an example, let’s create a Configmap named my-cm-bp containing the build-time properties to load. You can alternatively use any Configmap you’ve already stored in your cluster:

kubectl create configmap my-cm-bp --from-literal=quarkus.application.name="my-great-application" --from-literal=quarkus.banner.enabled="true"

Here, as an example we have create a configmap with 2 Quarkus properties.

build-property-route.yaml
- 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.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.

Property from ConfigMap/Secret as file

When you have a lot of key-value pairs to store into a given ConfigMap/Secret, you may consider storing some build-time properties as a file into a specific key-value pair for the sake of simplicity.

The only constraint is to use .properties as a suffix of the key to indicate that the value is actually a property file, not a simple value.

As an example, let’s use the same Integration as the previous section but with a ConfigMap that contains all the properties into the same key-value pair.

For this we need a properties file as next:

quarkus.properties
quarkus.application.name = my-super-application
quarkus.banner.enabled = true

That we will load into a specific ConfigMap using the following command:

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.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.

Property collision priority

If you have a property repeated more than once, the general rule is that the last one declared in your kamel run statement will be taken in consideration. If the same property is found both in a single option declaration and inside a file/configmap/secret, then, the single option will have higher priority and will be used.

Run time properties

If you’re looking for runtime properties configuration you can look at the runtime properties section.

Back to top