camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: git commit: CAMEL-7023: Added hawtio goal to camel maven plugin.
Date Sat, 30 Nov 2013 13:16:56 GMT

On Nov 30, 2013, at 2:35 AM, Robert Davies <rajdavies@gmail.com> wrote:

> 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. 


Having no way for this PMC to control the display of the Camel route *IS* a technical justification.
  If we as a PMC wanted to remove columns, add new columns for new features, change the order
of stuff, etc….   *WE* have no way to do so.   

Having no way to change the branding of what is displayed *IS* a technical justification.
  We cannot have links popping up and icons and such that promote something else.

Having no way to remove all the “cruft” that is unrelated to Camel *IS*  a technical justification.
  Claus’s screen shot on the wiki has an AcitveMQ tab, Wiki tab, etc…  which would need
to be removed if the goal is to have a Camel route display.

That’s all technical justification.    This needs to be removed until they can all be addressed.
 

Oh… and the maven goal cannot be camel:hawtio.   It would need to be camel:run-webconsole
or similar to remove the branding part from that as well.


Dan



> 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.
> 
> Rob
> [1] http://camel.465427.n5.nabble.com/DISCUSS-CAMEL-3-0-Does-camel-need-a-web-console-tt5726280.html#a5727053
> 
> On 29 Nov 2013, at 18:07, Daniel Kulp <dkulp@apache.org> wrote:
> 
>> 
>> On Nov 28, 2013, at 8:42 AM, James Strachan <james.strachan@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.strachan@gmail.com> wrote:
>>> 
>>>> On 28 November 2013 13:32, Daniel Kulp <dkulp@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: jstracha@redhat.com
>>>> Web: http://fusesource.com
>>>> Twitter: jstrachan, fusenews
>>>> Blog: http://macstrac.blogspot.com/
>>>> 
>>>> Open Source Integration
>>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> James
>>> -------
>>> Red Hat
>>> 
>>> Email: jstracha@redhat.com
>>> Web: http://fusesource.com
>>> Twitter: jstrachan, fusenews
>>> Blog: http://macstrac.blogspot.com/
>>> 
>>> Open Source Integration
>> 
>> -- 
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
> 
> Rob Davies
> -----------------
> Red Hat, Inc
> Twitter: rajdavies
> Blog: http://rajdavies.blogspot.com
> ActiveMQ in Action: http://www.manning.com/snyder/
> 

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message