camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET
Date Thu, 21 Feb 2013 02:49:02 GMT
I strongly disagree. On what are you basing your "MUST" statement?

There are 2 areas in which camel excels: one is the middleware 
abstraction, via the api. The second is the runtime mediation. The dsl 
has nothing to do with either, it's just syntactic sugar, eye candy. I 
don't deny that it's helpful especially if well thought out. But I 
certainly wouldn't go that far to state that there must be one 
authoritative source.

Cheers
Hadrian


On 02/16/2013 03:48 AM, Claus Ibsen wrote:
> On Sat, Feb 16, 2013 at 9:43 AM, Willem jiang <willem.jiang@gmail.com> wrote:
>> Hi Henryk,
>>
>> The static import of Builder method could resolve the dependency problem of Java
DSL.
>> But when we move to the Spring XML or Blueprint, we still need a DataFormat model
to hold the reference in the camel-core.
>>
>
> Yes there MUST be one authoritative source of the DSL which is the
> classes in the model package of camel-core.
> This model is then used to fully automatic generate the XML DSLs for
> spring and blueprint. This ensures we have a DSL that is in sync.
>
>
>> --
>> Willem Jiang
>>
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> Web: http://www.fusesource.com | http://www.redhat.com
>> Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
>>            http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
>> Twitter: willemjiang
>> Weibo: 姜宁willem
>>
>>
>>
>>
>>
>> On Thursday, February 14, 2013 at 4:02 AM, Henryk Konsek wrote:
>>
>>>> This was the today's discussion on IRC (irc://irc.codehaus.org/camel (http://irc.codehaus.org/camel)).
>>>
>>>
>>>
>>> You seem to have a nice party here :) . I must join the next week.
>>>
>>> @Hadrian:
>>> SCXML component is something I wanted for Camel for a really long
>>> time. I like the library very much and it would be great to have it in
>>> Camel. I'm glad you want to give it a chance.
>>>
>>> Regarding the Camel Core and DSLs - it would be great to move
>>> component-related DSL definitions from the core. For example XStream
>>> data format definition
>>> (org.apache.camel.model.dataformat.XStreamDataFormat) should be kept
>>> in the camel-xstream jar and somehow dynamically included in the DSL.
>>> I'm considering something similar to the the following snippet:
>>>
>>> import static org.apache.camel.dataformat.XStreamDslBuilder.*;
>>> ...
>>> from(...).marshal(xstream()).to(...);
>>>
>>> or even
>>>
>>> import static org.apache.camel.dataformat.XStreamDslBuilder.*;
>>> ...
>>> from(...).marshal(xstream).setXStream(...).to(...);
>>>
>>>
>>> In general static imports would be our friends here :) .I need to
>>> think about it and then I'll come with a concrete proposal.
>>>
>>> See you on the next IRC session (hopefully).
>>>
>>> --
>>> Henryk Konsek
>>> http://henryk-konsek.blogspot.com
>>
>>
>>
>
>
>

Mime
View raw message