davsclaus commented on issue #3964: URL: https://github.com/apache/camel-k/issues/3964#issuecomment-1408396923
Good suggestions in this thread, and I suggest to moving all of this into Camel K 2.x, and keep 1.x as-is. Here is some of my brain-dump Let Camel K 2 be based on: - Camel v4 - run->deploy via build pipelines as primary (gitops ... favour code in git not in CRD) - build using standard Quarkus / Spring Boot (via their maven package) - make application.properties|yaml first-class (and not modeline / complex confusing traits) - then you can use standard Q/SB way of configuring (also k8s specifics) - If Camel K needs to argument the build then have plugins/customizations to Q/SB build / application.properties /jbang script etc) - Maybe only allow Kamelet Binding in CRD (for small event based rules) - camel-jbang for local development - if you need to develop directly in k8s, then camel-jbang can possible be enhanced to do that - Let Camel K operator be able to manage also any kind of Camel deployments (also traditional CSB/CQE - for example via label selectors). Can be done later in 2.x. - Better unit testing (also needed in camel-jbang) (could maybe be yaks with jbang ?) - Cross-over from traditional CEQ/CSB to Camel-K would then be much smoother and similar UX, and vice-versa, eg you start with Camel K and then want to do a full standard maven based project, and move over to CSB/CQE -- 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]
