Pasquale Congiusti

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

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.

Running a local registry on Kind is a bit hacky (see https://camel.apache.org/camel-k/2.3.x/installation/registry/own.html#configuring-registry-run-docker). This is the reason why there is no "official" documentation around that.

`--set platform.build.registry.address=http://kind-registry:5000` is maybe `--set platform.build.registry.address=kind-registry:5000`

About the generic question, I've provided an answer in [#camel-k > ✔ Camel K Quarkus ConfigMap Properties @ 💬](https://camel.zulipchat.com/#narrow/channel/257299-camel-k/topic/.E2.9C.94.20Camel.20K.20Quarkus.20ConfigMap.20Properties/near/516848301)

> This may or may not be related, but if using the standard .properties `${}` placeholder syntax, camel k is unable to resolve these... meaning using `{{base.fqdn}}` in an integration...

Hello, I had a look again and I think I got now what the problem is. The `plain-quarkus` runtime is not (yet) able to scan a properties file coming from...

It's the camel framework version. Camel K uses a runtime (in case of Quarkus, camel-quarkus) which depends on a given camel core version see [1]. Likely next Camel Quarkus 3.29.0...