[GitHub] [camel-k] Delawen commented on issue #3964: [Discussion] Camel K 2023 roadmap

["Delawen (via GitHub)" <gi...@apache.org>]

Delawen commented on issue #3964:
URL: https://github.com/apache/camel-k/issues/3964#issuecomment-1411573462

   I like the idea of extending Camel K a tool that handles all potential Camel runtimes around K8. At least for me it makes sense from the point of view of an integration developer. One command line to interact with the cluster in all Camel sense. Install, deploy, monitor,...
   
   Not to mention it also makes sense to me as a way to easily connect other libraries and applications (obviously thinking on the editor Kaoto.io here). 
   
   JBang can be adapted to use K8, alright, but we already have Camel K that does it for many DSLs. Why should we cut down features we already have in Camel k? Enhancing JBang doesn't mean cutting down Camel K which already works. Maybe even the adaptation of JBang to interact with the cluster could be done via camel-k. That would make sense to me, reusing existing resources.


-- 
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-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org