On Nov 28, 2013, at 8:42 AM, James Strachan <james.strac...@gmail.com> wrote:
Should we back out the use of graphviz too? Do you think generating images
for camel routes should be -1'd too?
No. Graphviz is a graphics library. ALL the code for taking the camel
routes and feeding the information into graphiz lives in camel and is under the
Camel PMC control and direction. How the graph is presented to the user is
under the Camel PMC direction. Thus, it’s “OK”.
In this case, all of the code for presenting the Camel UI is NOT in control of
the Camel PMC. It’s not part of Camel. It’s completely under the control of
an external party. That is NOT OK.
If HawtIO was just a console framework (or whatever you want to call it) and
all of the “Camel” value-add was a plugin or was built upon that and that code
was in Camel, I’d have “less” of a concern (certain branding and links and doc
things would need to be resolved as well). Basically, if it was like Spring
where Spring has a core and all the camel value add stuff to spring (namespace
handlers, spring integration stuff, etc…) is part of Camel, then it would be OK.
So, in summary, if a user wants a nice graphics view of a Camel route, as far
as the Camel project goes, there are three options:
1) Claim it’s not an issue and do nothing….. It’s not one of our “itches” for
us to scratch.
2) Claim it is an issue, but outside the scope of our project and point people
the third party applications page we have on the website for options that are
available.
3) Expand the scope of Camel to include this, but in this case, it HAS to be
controlled, managed, documented, branded, etc…. completely by the Camel PMC.
How it’s presented to the user, etc… must be completely “Apache Camel”, not
hawtio or what ever.
Take your pick.
Dan
On 28 November 2013 13:41, James Strachan <james.strac...@gmail.com> wrote:
On 28 November 2013 13:32, Daniel Kulp <dk...@apache.org> wrote:
I’m -1 to this commit. I don’t think we should be adding a bunch of
targets for all the various container/platform integrations.
If that were true I'd maybe -1 it too; but this commit looks to be about
making it easy for Camel users to visualise & debug Camel routes in a web
browser - from inside their existing maven camel project. i.e. its a camel
thing; just needs a web server to host some static HTML/CSS/JS (which is
purely an implementation detail).
Though its nothing really to do with mimicking runtime platforms like
tomcat:run / karaf:run / jetty:run.
--
James
-------
Red Hat
Email: jstra...@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration
--
James
-------
Red Hat
Email: jstra...@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
