camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Davies <>
Subject Re: git commit: CAMEL-7023: Added hawtio goal to camel maven plugin.
Date Sat, 30 Nov 2013 07:35:54 GMT
It seems a couple of people are getting a head of themselves.
Firstly, the -1 vote  of Dan and Hadrian are invalid without a technical justification,  and
it seems they are trying to justify a -1 on some policy by the Camel PMC that I for one are
not aware of. 
We have discussed removing the camel console [1], but that discussion is insufficient to cover
the case of adding a maven target to different console - its not being distributed as part
of Apache Camel, its just making it easier to run if you want to.  I understand the concerns
about hawtio,  but lets discuss that first - and on a different thread and get some formality
into this please.


On 29 Nov 2013, at 18:07, Daniel Kulp <> wrote:

> On Nov 28, 2013, at 8:42 AM, James Strachan <> 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 <> wrote:
>>> On 28 November 2013 13:32, Daniel Kulp <> 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:
>>> Web:
>>> Twitter: jstrachan, fusenews
>>> Blog:
>>> Open Source Integration
>> -- 
>> James
>> -------
>> Red Hat
>> Email:
>> Web:
>> Twitter: jstrachan, fusenews
>> Blog:
>> Open Source Integration
> -- 
> Daniel Kulp
> -
> Talend Community Coder -

Rob Davies
Red Hat, Inc
Twitter: rajdavies
ActiveMQ in Action:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message