Hi We are on a good start for 2022 and we have experimented a bit during a few PTO days during the christmas break.
I put together some thoughts for how we can improve the developer productivity with Camel and also make Camel more accessible for new users, and low-code integrators. 1) Route source location:line-number ============================ https://twitter.com/davsclaus/status/1477981936119435264?s=20 We are now able during bootstrap to parse the route models and gather the exact source file and location for each EIP node in all the routes across all DSL types (Java, Groovy, Kotlin, XML, YAML etc.) The XML and YAML are "free" as the parser already captures this. Well not for the legacy Spring <beans> and OSGi Blueprint XML files as they are parsed with JAXB that does not offer such a feature. But for modern Camel with route snippet XML files on Spring Boot, Camel-K etc it's not a problem - we use the fast camel-xml-io parser. With this information at hand, it offers greater feedback to the developer about where in the source a Camel Exchange failed, or its routing path, or message tracing, etc. For example we can dump a "stacktrace" on error, that a developer can then from the IDE click on the line and the IDE will position the editor to the exact location. I have created a bunch of JIRAs where we can take advantage of this now. Another great win is that this allows Camel Route Debugger tools for IDEA, VSCode, Eclipse etc to be able to do route debugging just like you do regular Java debugging. The IDEA plugin 0.8.1 release has early support for this with XML and Java DSL. There is a "small penalty" to pay when gathering this for Java, Groovy, Kotlin, during bootstrap of Camel. Therefore we will add a flag where you can turn this on|off accordingly. For Camel Quarkus we can take advantage of its build step where we can automatically capture this during build, and then at runtime there is no overhead. https://github.com/apache/camel-quarkus/issues/3432 We are already started on this and this will be included in the next Camel 3.15 release. 2) Developer Mode =============== To make development easier with Camel we should introduce a developer mode that automatically turns on various "things" and comes with "batteries included". Such as the source location:line-number from (1), and other settings enabled that makes development easier. And when in development mode, we can also log during startup "things" that will assist the developer. For example I have experimented with logging all the HTTP path:port that Camel exposes on startup, so you can easily find out which URL a rest-dsl service is exposed on, or what the "developer console" / "health-check" url is etc. For example Quarkus has a developer mode, e.g. when you run mvn quarkus:dev. And with Camel JBang we have its --reload functionality that should be enabled in development mode, so Camel will automatically reload on saved changes. We should introduce this in Camel 3.15. 3) Developer Console ================= https://issues.apache.org/jira/browse/CAMEL-17384 I worked on a prototype so we can build developer consoles that are pluggable. Meaning that you can build out of the box consoles from the core, and then per component etc. Developer Console is really cool and Quarkus comes with this https://quarkus.io/guides/dev-ui With the DevConsole SPI in camel-core then we should make these consoles generic, so they can be used in any runtime. We should build a web console for Camel JBang. And then for Camel Quarkus we should use the Quarkus UI etc. And for Spring Boot we can use what we do for Camel JBang as a generic web console. For DevConsole we can expose many interesting things from a Camel application. We can list all the running routes, and their performance metrics. We can make a console that profiles the routes, and highlights the "most slowest" etc. We can show a table with the last N events. We can have a console for message tracing. And many more ... So each console should expose the "data" in a canonical way, eg JSon structure. That the web ui can then use to render nicely. We could also consider a plain text based that CLI tools can use, or that can be used for troubleshooting / development of the console. We can introduce the DevConsole SPI API in Camel 3.15 and come with some tech preview consoles in the release. And then over the next couple of releases continue to add more consoles, and build up a UI for jbang / spring-boot, and for camel-quarkus then use what quarkus offers. 4) Camel JBang ============ We should continue to work on camel-jbang as it's a fantastic new toy, to introduce Camel to new users that do not come with a Java developer background. With jbang you can try out Camel quickly. All you need to do is to "install jbang" then it can take care of installing JDK if needed, and then you can run Camel from a single command, where it downloads all it needs. There is a PR on the way that allows to "continue" to make this a Maven project https://github.com/apache/camel/pull/6583 This means that after the user has built a prototype with jbang, and a bit more power is needed then that can easily be turned into a Maven project you can load into VSCode / IDEA and work with. We should continue to innovate here. And also promote this more with more blogs, videos, social media etc. 5) Karavan ========= https://github.com/apache/camel-karavan The Karavan Camel UI designer is already integrated with camel-jbang, meaning that you can quickly start here and build a prototype or complete integration. Marat will continue working on this so expect great progress here. And then some thoughts on low-code integrations where we have pieces in Camel that was born for the Camel K world, but we made them generic, and now there is potential to make this play a bigger role for the future of Camel. 6) Kamelets ========== We will continue to add more kamelets for sinks and sources as needed. Kamelets work great with Karavan and camel-jbang for low-code integrations. 7) Kamelet Binding =============== The Kamelet Binding is potentially something that is not only usable on Kubernetes. We have made it possible to run a binding yaml file in standalone mode too. This is something that appeals to the low-code integration - where you may bind 2 systems together with kamelets, and then if needed add a data mapping (such as via altasmap) and if needed set up some error handling (part of binding). A regular Camel route scenario is of course also possible, but a yaml binding file may be "simpler" and also portable to camel-k and kubernetes. Okay my cup of coffee is empty, over and out. -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
