@squakez -- please review this.

Correct, and setting camel.main.cloud-properties-location explicitly does work.

• When using plain-quarkus and providing a generic configmap (non file-based), it is already automatically setting this cloud location and the properties are able to be read successfully.
• Even if this configmap is file-based, it still auto-sets the location, it is just unaware that it needs to parse the configmap a bit differently.

The default runtime currently has awareness of how to handle this scenario, somehow, as it works (as shown in these tests). What I am questioning is why similar logic can't be used to auto-handle this scenario.

Ok, I got your point. The "problem" is that the plain runtime is not aware of where it is running (it could not be necessarily on a cloud environment), so, it must be instructed specifically where to look for by setting the following camel property camel.component.properties.location=file:/tmp/my.properties. You can add multiple locations and, ideally, you can combine the possibility to mount the configmap in a given location togheter with this property. In that case the runtime will be able to parse the file properly.

We can think to add something on Camel core, in order to be able to automatically parse any file with .properties in camel.main.cloud-properties-location similarly of what the Camel K runtime is doing. I suggest you to report on main Camel project in order to be widely discussed with the community.

This PR has been automatically marked as stale due to 90 days of inactivity.
It will be closed if no further activity occurs within 15 days.
If you think that’s incorrect or the issue should never stale, please simply write any comment.
Thanks for your contributions!

I finally ended up creating the request and making the development: see https://issues.apache.org/jira/browse/CAMEL-22489 - we can run this again when the new runtime is available (likely quarkus 3.29.0).

Camel Quarkus 3.29.0 is on vote. As soon as it is released (likely next week) we'll run this against the new runtime and be able to merge it.

Let's merge this and we can evaluate if it passes nightly tests against plain-quarkus runtime.