squakez commented on issue #3964: URL: https://github.com/apache/camel-k/issues/3964#issuecomment-1409954112
Thanks @davsclaus for your latest feedback, it's a valid vision of future goals for sure. IMO we're not in the position to do a full redesign of the project (we may require a lot of development resource we don't have ATM), although, trying to resume your points, we should aim to make Camel K the deployment tool for Kubernetes Camel applications (whichever runtime the user want to choose). For this reason the main aim is to decompose as much as we can the building part, to make it more explicit and be able in a following iteration to hook with anything Camel related (being a generic Maven project, a git repo, etc...). For this reason, we should not be afraid of introducing _some_ breaking change (therefore having a major Camel K 2.0). However, as pointed out by @oscerd we still have a valid design, but we definitely need to think ahead of time of what we eventually want to have, so that Camel K 2.0 could be a more flexible design to simplify future Camel K version developments. The build part is quite strategic and focusing on that together with decoupling from Camel runtime is going a big part of these changes. -- 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
