You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Christian Müller <ch...@gmail.com> on 2013/02/12 21:58:16 UTC
[DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET
This was the today's discussion on IRC (irc://irc.codehaus.org/camel). Feel
free to join the next time and/or comment on the today's discussed items.
The next one is scheduled for 02/19/2013 7:00PM - 8:00PM CET. Feel free to
join and express your ideas/needs/whishes/...
02/12/2013 7:00PM - 8:00PM CET - DISCUSSING THE CAMEL 3.0 ROAD MAP
[19:01:58] <cmueller> so, lt's talk about our Camel 3.0 ideas and the
road map in the next hour...
[19:02:20] elakito (~elakito@mnhm-5f75f2b2.pool.mediaWays.net) joined
the channel.
[19:03:31] hadrian is around
[19:04:09] <cmueller> I sent out a few mails to our committers (and I
have to send out some more)
[19:04:41] <cmueller> and kindly ask to join our discussion - online or
offline
[19:05:18] <cmueller> and may be the champion for one or more of our
ideas
[19:05:50] <cmueller> I hope we will see a more active discussion in
the comming days
[19:06:05] <hadrian> next week i won't be around
[19:06:22] <hadrian> the week after, see you at acna2013
[19:07:22] <cmueller> yeah
[19:07:55] scranton (~scranton@66.187.233.206) left IRC. ("")
[19:08:10] <cmueller> I hope we find time to discuss Camel 3.0 in
Portland too
[19:08:32] <hadrian> there'll be plenty of time in the evening... and
beer
[19:08:32] <cmueller> maybe with some other users/contributors
[19:08:40] <hadrian> who do we know is going?
[19:08:43] <hadrian> absolutely
[19:10:05] <cmueller> I think we have to look for a good place and
announce it on the dev/users list
[19:10:19] <hadrian> yeah, that'd work
[19:10:22] <cmueller> I'm available every evening ;-)
[19:11:00] rajdavies (~
textual@host86-161-249-129.range86-161.btcentralplus.com) left IRC.
("Textual IRC Client: www.textualapp.com")
[19:11:49] <cmueller> When do you plan to arrive?
[19:12:09] <hadrian> i think i'll get there Mon afternoon, need to check
[19:12:25] <cmueller> me too
[19:13:33] <cmueller> 25 February 4:00 PM
[19:14:28] <hadrian> i don't have a lot of time today
[19:14:37] <hadrian> anything in particular anybody wants to discuss?
[19:15:14] <hadrian> ok, i'll throw one out there, i think we touched
on that before
[19:15:26] <cmueller> Not from my site. I will use the time to transfer
some of my ideas to the road map
[19:15:39] <hadrian> i did a lot of reading/research lately
[19:15:45] rnewcomb (~rnewcomb@lvcc.zappos.com) left IRC. ("This
computer has gone to sleep")
[19:15:47] iocanel (~textual@athedsl-88751.home.otenet.gr) left IRC.
("Computer has gone to sleep.")
[19:15:52] <hadrian> and there is an area underused with camel
[19:15:59] <hadrian> that has to do with api
[19:16:30] <hadrian> there are a bunch of coops/consortia that define
their own apis/sets of wsdls
[19:16:48] <hadrian> we do support that in camel, we have things like
gae, hl7
[19:16:53] <hadrian> both apis and dataformats
[19:17:32] <hadrian> but i don't think we make it clear enough how one
could have components targeted at integrating messages
[19:17:48] <cmueller> don't forget paypal
[19:17:53] <hadrian> specific to an industry into a larger app,
involving accounting, etc
[19:18:06] <hadrian> things like saleforce, you name it
[19:18:18] <cmueller> and other like saleforce
[19:18:23] <cmueller> :-)
[19:18:38] <hadrian> and related to that, i think security identity
must be part of the camel api
[19:18:51] <hadrian> security and identity i mean
[19:18:55] <hadrian> authn/authz
[19:19:32] gnodet (~gnodet@ven14-2-82-235-193-35.fbx.proxad.net) left
IRC. (gnodet)
[19:19:43] <hadrian> running a route as, processing a message on behalf
of
[19:20:12] gnodet (~gnodet@ven14-2-82-235-193-35.fbx.proxad.net)
joined the channel.
[19:20:21] <cmueller> good point
[19:20:31] <hadrian> should probably add a story about that in -ideas
[19:20:44] <hadrian> then we need expressions, of course
[19:21:03] <hadrian> to support idenentity/role based cbr/filters
[19:21:16] <cmueller> true
[19:22:02] <hadrian> but the cool thing is not much has to change, just
add the expressions
[19:22:20] chm007 (~cmoullia@ip-83-134-63-222.dsl.scarlet.be) left
IRC. ("Computer has gone to sleep.")
[19:22:50] <cmueller> and a few dsl extensions I guess
[19:23:13] <hadrian> another thing i looked at recently is scxml, i'll
write a component for it too, probably at acon
[19:23:28] <hadrian> i don't think we need dsl extensions
[19:23:37] <hadrian> actually i start to dislike the dsl more and more
[19:24:11] <hadrian> we have things like routingSlip and recipientList
in the dsl, fine, kinda clear eips
[19:24:30] <hadrian> but what about setHeader? that'd be a transform as
an eip
[19:24:48] <hadrian> so my 2 issues are that
[19:25:17] <hadrian> 1. we mix methods/eips from different layers of
abstractions, which makes things confusing
[19:25:37] <hadrian> 2. it grew constantly and became a little monster
[19:26:00] <hadrian> but hey, that's my personal view
[19:26:29] <hadrian> if we isolate it in a separate bundle it's less of
an issue
[19:26:38] gnodet (~gnodet@ven14-2-82-235-193-35.fbx.proxad.net) left
IRC. (gnodet)
[19:26:43] <cmueller> I think your view is not totally wrong ;-)
[19:26:48] <hadrian> maybe we can even layer dsl
[19:26:54] <hadrian> kinda the way we do in bam
[19:27:28] <cmueller> I have to check this
[19:27:40] <cmueller> didn't looked into it for a long time
[19:29:41] <hadrian> one question, any ideas of how to measure the 99%+
compatibility cibsen mentioned?
[19:29:53] iocanel (~textual@athedsl-88751.home.otenet.gr) joined the
channel.
[19:30:13] <cmueller> no idea
[19:30:22] <hadrian> i recently went through a similar experience with
jacob
[19:30:29] <cmueller> We can do a lot
[19:30:37] <hadrian> so i refactored a lot in jacob without touching
the tests at all
[19:30:52] <cmueller> but no idea how to measure it...
[19:30:58] <hadrian> the fact that they still passed told me that the
refactoring worked and is compatible
[19:31:10] <hadrian> or that the coverage was insufficient :)
[19:31:19] <hadrian> but that wasn't my problem :)
[19:31:24] <cmueller> hehe
[19:31:52] <cmueller> But if we provide support
[19:31:56] <hadrian> so after we refactor the camel tests to make them
more like unit tests and easier to manage
[19:32:09] <cmueller> for upgreading to Camel 3.0 with some scripts
[19:32:19] <hadrian> i was thinking to maybe keep them separately, or
not change them at all or something
[19:32:31] <cmueller> they may change imports, some dsl expressions, ...
[19:32:44] <cmueller> is this compatible or incompatible?
[19:32:53] <hadrian> cmueller: my thinking was to have camel-rt-*.jars
[19:33:23] <hadrian> and then a camel-core.jar for backwards
compatibility as an uber jar over rt *plus* extra apis/impl for
compatibility
[19:33:42] <cmueller> like cxf
[19:33:56] <hadrian> pretty much, learn from the smart guys
[19:34:30] <cmueller> why not...
[19:35:01] <cmueller> the dsl could also go into its own bundle
[19:35:04] <hadrian> since cibsen cares so much about the compatibility
we should volunteer him as the champion :)
[19:35:28] <hadrian> yes and also in camel-core, so it won't impact
users until they migrate
[19:36:46] <hadrian> that's all on my side and i gotta go shortly
[19:37:07] <cmueller> There are some other committers I would like to
see as a champion
[19:37:41] <cmueller> ok, do you plan to put these ideas on the idea
page?
[19:37:51] <cmueller> we should not forget it
[19:37:59] <hadrian> i'll put the security one
[19:38:03] <cmueller> security stuff, ...
[19:38:08] <cmueller> ok, cool
[19:38:39] <hadrian> measuring the compatibility is a trickier thing,
not sure how to get consensus on that one
[19:38:43] <cmueller> I will add some comments on the "Split camel-core
into multiple parts" idea
[19:39:02] <hadrian> everybody i think agrees in principle, but i am
not sure how we'll agree on how to go about it
[19:39:33] <hadrian> yeah, that's there already, but the issue is how
do you ensure compatibility, what guarantees we make, etc
[19:39:44] <cmueller> I think someone has to start hacking
[19:40:18] <cmueller> and than more and more people get a concrete idea
about what he plan
[19:40:28] <cmueller> t do
[19:41:02] <cmueller> and the discussion will rise
[19:41:32] <hadrian> the only thing to be done now, really is improving
the testing, imho
[19:42:22] hadrian has 3 min left
[19:42:29] <cmueller> I think we can do more
[19:42:43] <cmueller> but let's discuss this the next time
[19:43:04] <cmueller> after ApacheCon NA I also have more time for this
[19:43:07] <cmueller> :-)
[19:45:21] <cmueller> ok, take care
Best,
Christian
--
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM
CET
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Hi,
You can of course implement a processor (or an endpoint) that
encapsulates an execution engine powered by scxml (or bpel, or other
language for that matter).
That discussion however took place in a different context, externalizing
the dsl. But you are correct, we could implement support for scxml today
in 2.x. Supporting scxml as a camel first class dsl though would require
the refactoring we intend for 3.0.
In a similar context I had a few chats with Tammo from ODE, who has some
very interesting ideas about refactoring the model, based on use cases
they for BPEL with models simply too large to fit in memory (100+ Mb
iirc). I think camel doesn't come even close to support such usecases
because we don't support partial execution models.
I will talk about using Camel for long running processes at CamelOne
2013 [1] (thanks to organizers for accepting my talk) and I could
comment a bit on the need for partial execution models if there would be
any interest in that.
Cheers,
Hadrian
[1] http://fusesource.com/apache-camel-conference-2013/
On 05/04/2013 06:56 AM, Murray.hughes wrote:
>> [19:23:13] <hadrian> another thing i looked at recently is scxml, i'll
>> write a component for it too, probably at acon
> Does scxml really need v3? Surely it can work just fine in camel 2?
> I imagined two interfaces -
> A producer that sends an event to an scxml executer, and a eventDispatcher
> that receives sends from scxml, sending them to consumers.
>
> examples using jexl:
> <state id="state6">
> <transition event="exchange" target="state7"
> cond="_eventdata.getProperty('key') eq 7"/>
> <transition event="exchange" target="state8"
> cond="_eventdata.in.body eq 7"/>
> </state>
> <state id="state7" final="true"/>
>
> A producer drives it by triggering an event:
> //exchange.setProperty("key", new Integer(7));
> Message message = new DefaultMessage();
> message.setBody(new Integer(7));
> exchange.setIn(message);
> te = new TriggerEvent("exchange", TriggerEvent.SIGNAL_EVENT,
> exchange);
> exec.triggerEvent(te);
> Which transitions from state6 to state7.
>
> Exchange headers can be saved in the state context domain model:
> message.setHeader("key", "val");
> te = new TriggerEvent("exchange", TriggerEvent.SIGNAL_EVENT,
> exchange);
> exec.triggerEvent(te);
> <state id="state9" final="true">
> <onentry>
> <assign name="dmone" expr="_eventdata.in.header['key']" />
> </send>
> </onentry>
> </state>
> But the exchange can't be updated and returned to camel (that I know of), so
> its a one way trip.
>
> To go from scxml to camel the scxml Send Event calls a custom
> EventDispatcher:
> <state id="state9" final="true">
> <onentry>
> <assign name="dmone" expr="_eventdata.in.header['key']" />
> <send event="'body'" type="'t'" target="'jms:x'"
> targettype="'camelEndPoint'" namelist="dmone dmtwo">
> </send>
> </onentry>
> </state>
> The scxml domain model items must be named on the send namelist (dmone,
> dmtwo in the above example).
>
> EventDispatcher eventDispatcher = new EventDispatcher() {
> public void cancel(String sendId) {
> }
> public void send(String sendId, String target, String targetType,
> String event, Map params, Object hints, long delay,
> List externalNodes) {
> }};
> An implementation of the EventDispatcher should be able to create an
> exchange, assign the event to the body, the params to the exchange
> headers/properties, look up the endpoint.
> Again its a one-way trip.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-CAMEL-3-0-weekly-IRC-chat-at-02-12-2013-7-00PM-8-00PM-CET-tp5727462p5732013.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM -
8:00PM CET
Posted by "Murray.hughes" <mu...@gmail.com>.
>[19:23:13] <hadrian> another thing i looked at recently is scxml, i'll
>write a component for it too, probably at acon
Does scxml really need v3? Surely it can work just fine in camel 2?
I imagined two interfaces -
A producer that sends an event to an scxml executer, and a eventDispatcher
that receives sends from scxml, sending them to consumers.
examples using jexl:
<state id="state6">
<transition event="exchange" target="state7"
cond="_eventdata.getProperty('key') eq 7"/>
<transition event="exchange" target="state8"
cond="_eventdata.in.body eq 7"/>
</state>
<state id="state7" final="true"/>
A producer drives it by triggering an event:
//exchange.setProperty("key", new Integer(7));
Message message = new DefaultMessage();
message.setBody(new Integer(7));
exchange.setIn(message);
te = new TriggerEvent("exchange", TriggerEvent.SIGNAL_EVENT,
exchange);
exec.triggerEvent(te);
Which transitions from state6 to state7.
Exchange headers can be saved in the state context domain model:
message.setHeader("key", "val");
te = new TriggerEvent("exchange", TriggerEvent.SIGNAL_EVENT,
exchange);
exec.triggerEvent(te);
<state id="state9" final="true">
<onentry>
<assign name="dmone" expr="_eventdata.in.header['key']" />
</send>
</onentry>
</state>
But the exchange can't be updated and returned to camel (that I know of), so
its a one way trip.
To go from scxml to camel the scxml Send Event calls a custom
EventDispatcher:
<state id="state9" final="true">
<onentry>
<assign name="dmone" expr="_eventdata.in.header['key']" />
<send event="'body'" type="'t'" target="'jms:x'"
targettype="'camelEndPoint'" namelist="dmone dmtwo">
</send>
</onentry>
</state>
The scxml domain model items must be named on the send namelist (dmone,
dmtwo in the above example).
EventDispatcher eventDispatcher = new EventDispatcher() {
public void cancel(String sendId) {
}
public void send(String sendId, String target, String targetType,
String event, Map params, Object hints, long delay,
List externalNodes) {
}};
An implementation of the EventDispatcher should be able to create an
exchange, assign the event to the body, the params to the exchange
headers/properties, look up the endpoint.
Again its a one-way trip.
--
View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-CAMEL-3-0-weekly-IRC-chat-at-02-12-2013-7-00PM-8-00PM-CET-tp5727462p5732013.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM -
8:00PM CET
Posted by Willem jiang <wi...@gmail.com>.
I think the namespace handler are both supported in Spring and Blueprint, we can leverage that to decouple the extended DSL DataModel and Camel core.
One tricky thing is we need to find a way to publish the schemas for the extended DSL which could be used for validation.
--
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 7:35 PM, Henryk Konsek wrote:
> > Most popular camel syntaxes do not support extensions by 3rd party elements (I mean Java and XML).
> > Everything then goes directly to core.
>
>
>
> Extending Scala DSL is trivial as Scala provides traits and implicit
> conversions.
>
>
> As i mentioned already in Java is doable if we deprecate chained
> builder syntax like...
>
> from(...).marshal().xstream().to(...)
>
> ... in the favor of nested builders and static imports...
>
> import static org.apache.camel.dataformat.XStreamDslBuilder.*;
> from(...).marshal(xstream()).to(...);
>
> ...and parametrized DataFormatDefinition (with static imports for
> syntactic sugar)...
>
> import static org.apache.camel.dataformat.XStreamDslBuilder.xstream;
> from(...).marshal(xstream).setXStream(...).to(...);
>
>
> The bigger issue is the XML DSL syntax. Maybe additional namespace per
> component will solve the issue? But I'm not so sure if this approach
> will address our requirements.
>
> > Camel core should be separated from DSL.
> > DSL should be built on top of core, not otherwise.
>
>
>
> +1
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET
Posted by Henryk Konsek <he...@gmail.com>.
> Most popular camel syntaxes do not support extensions by 3rd party elements (I mean Java and XML).
> Everything then goes directly to core.
Extending Scala DSL is trivial as Scala provides traits and implicit
conversions.
As i mentioned already in Java is doable if we deprecate chained
builder syntax like...
from(...).marshal().xstream().to(...)
... in the favor of nested builders and static imports...
import static org.apache.camel.dataformat.XStreamDslBuilder.*;
from(...).marshal(xstream()).to(...);
...and parametrized DataFormatDefinition (with static imports for
syntactic sugar)...
import static org.apache.camel.dataformat.XStreamDslBuilder.xstream;
from(...).marshal(xstream).setXStream(...).to(...);
The bigger issue is the XML DSL syntax. Maybe additional namespace per
component will solve the issue? But I'm not so sure if this approach
will address our requirements.
> Camel core should be separated from DSL.
> DSL should be built on top of core, not otherwise.
+1
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET
Posted by Łukasz Dywicki <lu...@code-house.org>.
We have implementation of SCA parser based on DOM api [1]. As long as Spring or Blueprint allows to access document does it will work [2]. Not sure if JAXB will be capable to handle that and last thing I would like to see is hand written mapping between elements and DSL representations. The main problem with Spring/Aries are multiple schema locations. Both expects only one. This impiles creation of composite schemas which imports all others [3]. As long as Catalog/Schema resolver is able to follow include and import statements it should work. Someone just need experiment. ;-)
[1] https://github.com/jboss-switchyard/core/tree/master/config/src/main/java/org/switchyard/config/model/composite
[2] http://static.springsource.org/spring/docs/2.0.x/reference/extensible-xml.html#extensible-xml-parser
[3] https://github.com/jboss-switchyard/core/blob/master/config/src/main/resources/org/oasis-open/docs/ns/opencsa/sca/200912/sca-1.1-cd06.xsd
Cheers,
Łukasz Dywicki
--
luke@code-house.org
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org
> On Thu, Feb 21, 2013 at 11:25 AM, Łukasz Dywicki <lu...@code-house.org>wrote:
>
>> Keeping DSL syntax in core is caused by current design. Most popular camel
>> syntaxes do not support extensions by 3rd party elements (I mean Java and
>> XML). Everything then goes directly to core. That's wrong, that's really
>> bad. DSL should allow pluging new functors without problems. I mentioned
>> substitution group as desired design in XML Schema which will let us use
>> extensions.
>>
>
> Do you have any example of extensions working for spring or blueprint ? I
> can't find any good example from the top of my head, so I'm not even sure
> that it can actually be implemented (not from an xml perspective, but from
> a spring or blueprint one).
>
>
>>
>> To be honest, does camel-core care which dataformat is configured how?
>> Currently yes, however some of us already know it's not necessary. Camel
>> core should be separated from DSL. DSL should be built on top of core, not
>> otherwise.
>>
>> Cheers,
>> Lukasz
>>
>> Wiadomość napisana przez Willem jiang <wi...@gmail.com> w dniu 21
>> lut 2013, o godz. 04:06:
>>
>>> 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.jiang@gmail.com(mailto:
>> 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
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Feb 21, 2013 at 11:25 AM, Łukasz Dywicki <lu...@code-house.org>wrote:
> Keeping DSL syntax in core is caused by current design. Most popular camel
> syntaxes do not support extensions by 3rd party elements (I mean Java and
> XML). Everything then goes directly to core. That's wrong, that's really
> bad. DSL should allow pluging new functors without problems. I mentioned
> substitution group as desired design in XML Schema which will let us use
> extensions.
>
Do you have any example of extensions working for spring or blueprint ? I
can't find any good example from the top of my head, so I'm not even sure
that it can actually be implemented (not from an xml perspective, but from
a spring or blueprint one).
>
> To be honest, does camel-core care which dataformat is configured how?
> Currently yes, however some of us already know it's not necessary. Camel
> core should be separated from DSL. DSL should be built on top of core, not
> otherwise.
>
> Cheers,
> Lukasz
>
> Wiadomość napisana przez Willem jiang <wi...@gmail.com> w dniu 21
> lut 2013, o godz. 04:06:
>
> > 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.jiang@gmail.com(mailto:
> 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
> >>>>
> >>>
> >>
> >
> >
> >
>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET
Posted by Łukasz Dywicki <lu...@code-house.org>.
Keeping DSL syntax in core is caused by current design. Most popular camel syntaxes do not support extensions by 3rd party elements (I mean Java and XML). Everything then goes directly to core. That's wrong, that's really bad. DSL should allow pluging new functors without problems. I mentioned substitution group as desired design in XML Schema which will let us use extensions.
To be honest, does camel-core care which dataformat is configured how? Currently yes, however some of us already know it's not necessary. Camel core should be separated from DSL. DSL should be built on top of core, not otherwise.
Cheers,
Lukasz
Wiadomość napisana przez Willem jiang <wi...@gmail.com> w dniu 21 lut 2013, o godz. 04:06:
> 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.jiang@gmail.com (mailto: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
>>>>
>>>
>>
>
>
>
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM -
8:00PM CET
Posted by Willem jiang <wi...@gmail.com>.
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.jiang@gmail.com (mailto: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
> > >
> >
>
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM
CET
Posted by Hadrian Zbarcea <hz...@gmail.com>.
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 <wi...@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
>>
>>
>>
>
>
>
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET
Posted by Henryk Konsek <he...@gmail.com>.
>> 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.
Yeah, static imports is the way to decouple the component-specific DSL
from core DSL, but I still don't got clear vision on how to decouple
Spring XML and Blueprint. I need to analyze XML DSL internals more
deeply before I come with the concrete proposal (if with any at all).
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Feb 16, 2013 at 9:43 AM, Willem jiang <wi...@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
>
>
>
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM -
8:00PM CET
Posted by Willem jiang <wi...@gmail.com>.
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
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET
Posted by Henryk Konsek <he...@gmail.com>.
> For regression tests of other OSS components Gump comes to my mind ;)
I need to ready about this tool before I can express eny opinion :) .
> I am sure that "the ASF" doesn't want to give guarantees to non-ASF
> components, while "the community" could (if they are willing to)...
The non-ASF components are Camel Extra to be exact? :) I'm not aware
of any other non-ASF components repository for the masses :) .
--
Henryk Konsek
http://henryk-konsek.blogspot.com
AW: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET
Posted by "Jan Matèrne (jhm)" <ap...@materne.de>.
For regression tests of other OSS components Gump comes to my mind ;)
I am sure that "the ASF" doesn't want to give guarantees to non-ASF
components, while "the community" could (if they are willing to)...
Jan
-----Ursprüngliche Nachricht-----
Von: Hadrian Zbarcea [mailto:hzbarcea@gmail.com]
Gesendet: Donnerstag, 14. Februar 2013 18:22
An: dev@camel.apache.org
Betreff: Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM -
8:00PM CET
Thanks Christian. That, plus what do you do once you get past say 200
components, what about 500?
How would you grow to that kind of number of components? Is it realistic?
Actually it is. But how many of those are gonna be hosted at Apache? What
kind of guarantees do we make for the non-ASF camel components? How do we
support other communities (camel-extra comes to mind)? What about regression
tests? Tools?
So the context is a bit larger. Henryk, I am sure you hit some the problems
yourself, while doing the work on camel-extra others (me
included) dodged for a good while.
Cheers
Hadrian
On 02/14/2013 12:15 PM, Christian Müller wrote:
> We IRC'ed about the question whether we should release every component
> each time or only the components we changed in this version. There are
> some pros and cons...
>
> Best,
> Christian
>
> Sent from a mobile device
> Am 14.02.2013 17:32 schrieb "Henryk Konsek" <he...@gmail.com>:
>
>>> Therefore I'll have to come back to this a bit later. Please ping me
>> again
>>> if I don't.
>>
>> Sure I will. :)
>>
>> BTW If the discussion took place on mailing list and it is easy to
>> Google, you could send me a link to an appropriate nabble archive (or
>> keywords) so I can make my homework.
>>
>> --
>> Henryk Konsek
>> http://henryk-konsek.blogspot.com
>>
>
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET
Posted by Henryk Konsek <he...@gmail.com>.
> We IRC'ed about the question whether we should release every component
> each time or only the components we changed in this version.
I've read the IRC archives from your previous meetings. So many things
to address there :) . I'll make some noise on our IRC meetings
starting from the next week :)
Regarding the components management. I'll think about this during the
weekend and came with some proposal for the Tuesday IRC session.
I'd like to take the championship over at least one task. We'll talk
about it at Tuesday as well. I need to think about it in the context
of my plans related to Camel Extra.
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM
CET
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Thanks Christian. That, plus what do you do once you get past say 200
components, what about 500?
How would you grow to that kind of number of components? Is it
realistic? Actually it is. But how many of those are gonna be hosted at
Apache? What kind of guarantees do we make for the non-ASF camel
components? How do we support other communities (camel-extra comes to
mind)? What about regression tests? Tools?
So the context is a bit larger. Henryk, I am sure you hit some the
problems yourself, while doing the work on camel-extra others (me
included) dodged for a good while.
Cheers
Hadrian
On 02/14/2013 12:15 PM, Christian Müller wrote:
> We IRC'ed about the question whether we should release every component each
> time or only the components we changed in this version. There are some pros
> and cons...
>
> Best,
> Christian
>
> Sent from a mobile device
> Am 14.02.2013 17:32 schrieb "Henryk Konsek" <he...@gmail.com>:
>
>>> Therefore I'll have to come back to this a bit later. Please ping me
>> again
>>> if I don't.
>>
>> Sure I will. :)
>>
>> BTW If the discussion took place on mailing list and it is easy to
>> Google, you could send me a link to an appropriate nabble archive (or
>> keywords) so I can make my homework.
>>
>> --
>> Henryk Konsek
>> http://henryk-konsek.blogspot.com
>>
>
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET
Posted by Christian Müller <ch...@gmail.com>.
We IRC'ed about the question whether we should release every component each
time or only the components we changed in this version. There are some pros
and cons...
Best,
Christian
Sent from a mobile device
Am 14.02.2013 17:32 schrieb "Henryk Konsek" <he...@gmail.com>:
> > Therefore I'll have to come back to this a bit later. Please ping me
> again
> > if I don't.
>
> Sure I will. :)
>
> BTW If the discussion took place on mailing list and it is easy to
> Google, you could send me a link to an appropriate nabble archive (or
> keywords) so I can make my homework.
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
>
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET
Posted by Henryk Konsek <he...@gmail.com>.
> Therefore I'll have to come back to this a bit later. Please ping me again
> if I don't.
Sure I will. :)
BTW If the discussion took place on mailing list and it is easy to
Google, you could send me a link to an appropriate nabble archive (or
keywords) so I can make my homework.
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM
CET
Posted by Hadrian Zbarcea <hz...@gmail.com>.
No, not really :). We talked about it in the past. It would take it much
more time than I have right now to explain for those who don't know the
context (I have to do this, since this is a public list).
Therefore I'll have to come back to this a bit later. Please ping me
again if I don't.
Cheers,
Hadrian
On 02/14/2013 10:55 AM, Henryk Konsek wrote:
>> Cool. Now the only thing we need is a way to manage all those components.
>> Come ready with a proposal :).
>
> What do you exactly mean by 'manage'? :) Do you refer to the maintenance burden?
>
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET
Posted by Henryk Konsek <he...@gmail.com>.
> Cool. Now the only thing we need is a way to manage all those components.
> Come ready with a proposal :).
What do you exactly mean by 'manage'? :) Do you refer to the maintenance burden?
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM
CET
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Cool. Now the only thing we need is a way to manage all those
components. Come ready with a proposal :).
Cheers,
Hadrian
On 02/13/2013 03:06 PM, Henryk Konsek wrote:
>> [19:15:52] <hadrian> and there is an area underused with camel
>> [19:15:59] <hadrian> that has to do with api
>> [19:16:30] <hadrian> there are a bunch of coops/consortia that define
>> their own apis/sets of wsdls
>
> Yeah, we also need Jira component in particular if you ask me :) . I
> even started to work on this, but changing the job interrupted my
> effort. I hope to reanimate this topic this year :) .
>
> [1] https://github.com/hekonsek/camel-jira
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
>
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET
Posted by Henryk Konsek <he...@gmail.com>.
> [19:15:52] <hadrian> and there is an area underused with camel
> [19:15:59] <hadrian> that has to do with api
> [19:16:30] <hadrian> there are a bunch of coops/consortia that define
> their own apis/sets of wsdls
Yeah, we also need Jira component in particular if you ask me :) . I
even started to work on this, but changing the job interrupted my
effort. I hope to reanimate this topic this year :) .
[1] https://github.com/hekonsek/camel-jira
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET
Posted by Henryk Konsek <he...@gmail.com>.
> This was the today's discussion on IRC (irc://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