[DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

Christian Mueller
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 (~[hidden email]) 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 (~
[hidden email]) 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 (~[hidden email]) left IRC. ("This
computer has gone to sleep")
[19:15:47]      iocanel (~[hidden email]) 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 (~[hidden email]) left
IRC. (gnodet)
[19:19:43] <hadrian>     running a route as, processing a message on behalf
of
[19:20:12]      gnodet (~[hidden email])
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 (~[hidden email]) 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 (~[hidden email]) 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 (~[hidden email]) 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

--
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

hekonsek
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

hekonsek
> [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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

hadrian
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
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

hekonsek
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

hadrian
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?
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

hekonsek
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

Christian Mueller
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" <[hidden email]>:

> > 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

hadrian
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" <[hidden email]>:
>
>>> 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
>>
>
Reply | Threaded
Open this post in threaded view
|

AW: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

Jan Matèrne (jhm)
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:[hidden email]]
Gesendet: Donnerstag, 14. Februar 2013 18:22
An: [hidden email]
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" <[hidden email]>:
>
>>> 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
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

hekonsek
In reply to this post by hadrian
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

hekonsek
In reply to this post by Jan Matèrne (jhm)
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

Willem.Jiang
In reply to this post by hekonsek
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



Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

Claus Ibsen-2
On Sat, Feb 16, 2013 at 9:43 AM, Willem jiang <[hidden email]> 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: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

hekonsek
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

hadrian
In reply to this post by Claus Ibsen-2
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 <[hidden email]> 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
>>
>>
>>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

Willem.Jiang
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 <[hidden email] (mailto:[hidden email])> 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
> > >  
> >  
>  



Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

Łukasz Dywicki
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 <[hidden email]> 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 <[hidden email] (mailto:[hidden email])> 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
>>>>
>>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

hekonsek
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/12/2013 7:00PM - 8:00PM CET

Guillaume Nodet
Administrator
In reply to this post by Łukasz Dywicki
On Thu, Feb 21, 2013 at 11:25 AM, Łukasz Dywicki <[hidden email]>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 <[hidden email]> 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 <[hidden email](mailto:
> [hidden email])> 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: [hidden email]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
12