> But for what concerns the future plans we had already in mind that crazy idea
> of creating a web-based mini-IDE, where you can write (code) your routes,
> have auto-completion through a backend language server, customize the
> integration details (e.g. components, configuration properties, passwords),
> and run them, with a immediate feedback on the UI through a log window.
With something like that in place, devs could iterate on integrations quickly:
change the code -> save -> instant redeploy.
> This is what we have in mind now :)
That is pretty much what I had in mind too 😄! Hawtio Online has what's needed
for the master API integration part. It could detect if the Camel-K CRD is
present and activates the plugin accordingly. The later would be able to
auto-discover the existing Camel-K definition / deployment and propose an edit
button that would lead to a mini-IDE. The UI image could be enriched with a LSP
container.
> Monitoring is the hardest part IMO. That's because currently we have a
> Deployment per integration that is always active, but later on we will drop
> this behavior to add the "scale to 0 feature". A simple example is a route
> like from("timer:job?period=1h").to("...") that will be probably materialized
> as a CronJob. This means there'll not be always a JVM with Jolokia to ask
> information to.
Jolokia is one source of monitoring (maybe more management actually). I am
planning to source monitoring data from Prometheus and the Metrics API in the
near future as well in Hawtio Online.
[ Full content available at: https://github.com/apache/camel-k/issues/77 ]
This message was relayed via gitbox.apache.org for [email protected]
