On 25 January 2013 22:23, Raul Kripalani <r...@evosent.com> wrote: > So if the reason for trashing the console out of the Camel code base is the > proven lack of development focus on it, I wonder if it'd make sense to > contact the person behind the camelwatch project to ask if he'd be willing > to contribute it to ASF. > > Fair enough it's not the slickest UI, but maybe he'll be happy to continue > evolving it here? > > What truly harms us is having an outdated console not lining up with the > real richness of our monitoring and management API. Other than that, > offering a basic & optional console from within this community is not a bad > idea. > > AFAIK, camelwatch is more up-to-date, so it could give us a leap in this > area.
I remember looking at camelwatch a while back & its a good effort. I tried to re-evaluate it again though I'm afraid I can't build it: [ERROR] Failed to execute goal on project camelwatch-api: Could not resolve dependencies for project org.camelwatch:camelwatch-api:jar:0.5-SNAPSHOT: Failure to find com.sksamuel.jmxc:jmxc:jar:1.0.0-SNAPSHOT Incidentally most of the things on the camel-watch roadmap we've already added to the hawtio camel plugin: https://github.com/sksamuel/camelwatch#roadmap so it'd be good to see what the delta is between them. Maybe camelwatch can reuse hawtio or vice versa? >From looking at the ReadMe and screen shots I think hawtio can do most of the same things now while being a 10X smaller WAR despite including other plugins (e.g. ActiveMQ, JMX & logging); though hawtio does't provide a REST API to Camel (it reuses jolokia for all JMX access). Maybe the REST API to Camel is something the Apache Camel project should provide? e.g. maybe we should refactor camel-web to just being a set of JAXRS beans that consoles & tooling can reuse & merge in any changes camel-watch made on the JAXRS side of things? -- James ------- Red Hat Email: jstra...@redhat.com Web: http://fusesource.com Twitter: jstrachan, fusenews Blog: http://macstrac.blogspot.com/ Open Source Integration
