essobedo commented on PR #954: URL: https://github.com/apache/camel-k-runtime/pull/954#issuecomment-1403866402
> The idea is good, but we need to make sure to have a correspondent development on Camel K side. IMO, it would be better that you prepare a different PR for each language that you want to add. Locally, on Camel K side, you can use the Camel K runtime project with your local changes (`make images [CAMEL_K_RUNTIME_DIR=/path/to/camel-k-runtime-project]`) to test the change you're doing on Camel K side as well. You may start with Java support that is a top one required [apache/camel-k#3023](https://github.com/apache/camel-k/issues/3023) (I see you've self assigned, great!). Once the development is ready and tested both on Camel K and runtime sides, you can issue a PR on both side. We'd merge it on the runtime, and immediately we can test in Camel K side (it will take the related snapshot of the runtime). > > I'd like to avoid to merge this as we would say we support something that is not yet ready on Camel K side. Wdyt? I understand your point of view but it is an egg and chicken problem, without this PR a dynamic logic cannot be implemented in Camel-K. Moreover, unless I missed something, according to what I can see in the code, the metadata are just ignored so adding new ones has no effect in Camel-K which also means that the current metadata `native` is not supported either. Anyway, let me do what you propose. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
