Hello Claus, Some thoughts inline
Il giorno mar 4 gen 2022 alle ore 10:36 Claus Ibsen <claus.ib...@gmail.com> ha scritto: > 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. > > > This looks super interesting. > 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. > I'd like to spend some time on helping on this side. > > > 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. > About the Kamelets I think we should have some kind of priorities, so we'll focus at least on beginning on a good subset of components/endpoint configurations. Another important point here is being able to support the Kamelet on every runtime: for example, I noticed some components are not yet Quarkus extension and so, while the Kamelet could work on plain camel on Jbang, it won't work on Camel-K. Having a single catalog it's important. Maybe we could add some information as annotation to state the supported runtimes? > > > 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. > I think there were some discussion about changing the name to Binding only or something similar. > > > > 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 >
