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