squakez commented on issue #4618: URL: https://github.com/apache/camel-k/issues/4618#issuecomment-1748650396
#4797 PR should solve this issue by moving the logic from a custom logic to something that is expected by the Camel runtime. @lburgazzoli please have a look and also I'd like to share with you the results of some experiments I did before ending up with this solution (which may be temporary while we address in a proper way). I tried to bundle the Kamelet spec as a resource to be included to the project at build time. However this is not actually feasible with the design we have in place. Basically we have a strong separation between the resource we manage at Integration level and the ones we manage at IntegrationKit and Build level. The IntegrationKit was designed to be Integration agnostic and there is no easy way to slip Integration resources into the Build. We did a minimal exception when we introduced the possibility to include sources for native builds (which I am reluctant to extend on other things): native are almost always meant to be built from scratch. I think this separation of concerns was (and possibly still is) a good thing. If we want however to move in a different direction and be able to still have an incremental image driven by the kit, we could think on an additional step where the Integration have an additional container image which contains resource (such as kamelets or others like in #4639). Definitely not a top priority for now, but I'd like to have some opinion for the future. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
