Build time properties

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:

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:

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 …​)

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:

The quarkus.banner.enabled is configured to show the banner during the Integration startup. Let’s use --build-property flag in conjunction with file:

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.

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:

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

The quarkus.banner.enabled is configured to show the banner during the Integration startup. Let’s use --build-property flag in conjunction with file:

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.

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:

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

Then we launch the run command with the --build-property flag whose value matches with the appropriate syntax to refer to my-cm-bps:

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.

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.

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