I think multiple DSL suppport is most important feature for Camel, as our competitor just only support one or none of them.
We got the some complains from the user that why does the Java DSL work, but the Spring DSL doesn't work. They treat it a bug not a small syntactic failure. It could be more easy if we can maintain the core module code in one place. When you add no data format, you need to remember to update the module class. BTW, We have lots of tests in Camel to make sure the Java DSL, Spring DSL and other DSL do they job righty. -- 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 21, 2013 at 10:49 AM, Hadrian Zbarcea wrote: > 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.ji...@gmail.com > > (mailto:willem.ji...@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 > > > > > >
