camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Müller <>
Subject [DISCUSS CAMEL 3.0] weekly IRC chat at 02/19/2013 7:00PM - 8:00PM CET
Date Tue, 19 Feb 2013 20:57:26 GMT
This was the today's discussion on IRC (irc:// Feel
free to join the next time and/or comment on the today's discussed items.
The next one is scheduled for 02/26/2013 7:00PM - 8:00PM CET. Feel free to
join and express your ideas/needs/wishes/...

[19:00:14] <cmueller>     let's DISCUSS THE CAMEL 3.0 ROAD MAP for the next
hour. Feel free to join and express your ideas/needs/wishes/...
[19:00:56] <cmueller>     you can find our ideas here:
[19:01:20] <cmueller>     and our road map here:
[19:04:51] <cschneid1>     I would like to bring up the routing engine idea
like discussed on the dev list recently
[19:05:12] <cmueller>     ok, go ahead...
[19:05:15] <splatch>     hey :-)
[19:05:23] <cmueller>     welcome
[19:05:33] <cschneid1>     Do you guys think we can change the core to
implement such an engine? Or do we need some extra precautions like I
[19:06:31] <splatch>     I think making core really thin have 1st priority
it will speed up all other tasks including this discussed today
[19:06:33] <cschneid1>     I see the risk that bigger changes in the core
may lead to a branch that is only released after a year .. if we are lucky
[19:06:49] <cmueller>     One of Claus goals is to be 99% backwards
[19:07:15] <cschneid1>     Yes .. that would  mean we can do no bigger
[19:07:25] <splatch>     IMO Camel 3.0 don't have to be backward compatible
at all, if we will continue this path there is no reason to work on 3.0
[19:07:31] <cmueller>     Because of this, I think we need some Adapter
[19:07:37] <cschneid1>     +1
[19:07:48] <cmueller>     to provide a transition from Camel 2.x to 3.x
[19:08:10] <cschneid1>     This is why we came up with the idea of creating
a new api that is really small
[19:08:14] <cmueller>     And if we reach 95%, that would be great
[19:08:32] <cmueller>     I like this idea
[19:08:40] <cschneid1>     Then move all components to the new api and
bridge to the old core
[19:08:59] <splatch>     user code will require dependency updates any way,
so having core depending on separate api is not problem, it will be bringed
by maven as transient dependency, right?
[19:09:01] <cschneid1>     After that we can quite freely change the core
and break no components
[19:09:15] <cschneid1>     yes
[19:09:55] <cschneid1>     I think simply refactoring the core right away
is much more difficult. I tried and did not get very far
[19:10:26] <cmueller>     I can imagine this...
[19:10:57] <cschneid1>     Even when we do not try to be compatible it will
be a long time till the core is stable again
[19:11:01]      szhem (~ joined the
[19:11:33] <cmueller>     I think it would be great to start with something
in a sandbox
[19:11:38] <cschneid1>     So I think one of the most important goals
should be to make sure we can release 3.0 quite soon after we start
[19:11:55] <cmueller>     so that others get a better idea about we plan
[19:12:04] <cmueller>     +1
[19:12:29] <splatch>     cmueller: what's about component releases - will
they be released together as now?
[19:12:53] <cmueller>     that's another topic we have to discuss
[19:13:02] <cmueller>     there are pros and cons
[19:13:22] <cschneid1>     yes
[19:13:22] <cschneid1>     How about creating the new api in sandbox with
either a small standalone engine or a bridge to core
[19:13:32] <cschneid1>     I propose with to stay with the current common
release to not change too much at the same time
[19:13:40] <cmueller>     managing 100, 200 components with different
version numbers could be end up in a versioning hell
[19:13:51] <cschneid1>     I agree
[19:14:07] <cschneid1>     Perhaps we can do that when we have a small and
stable api
[19:14:12] <davsclaus>     okay i am actually online today - just send some
[19:14:21] <cmueller>     cool!
[19:14:23] <splatch>     cmueller: pushing 200+ modules release where 150+
are same as before doesn't sound like proper versioning too
[19:14:41] <cmueller>     agree, but simpler ;-)
[19:14:44] davsclaus     i guess you talk about the release each component
[19:14:47] <cmueller>     for us...
[19:14:51] <cmueller>     yes
[19:14:58] <splatch>     I am scarred by numer of components too
[19:14:59] <davsclaus>     i don't like that, keep it as is, elease patches
every 6-8 weeks or thereabouts
[19:15:04] <davsclaus>     we just need more ppl cutting releases
[19:15:07] <cschneid1>     splatch: Yes .. but as of now each component
depends on camel-core .. so any change in core potentially breaks a
[19:15:09] <cmueller>     and the other topic is the new Camel API
[19:15:17] <cmueller>     we are multi threaded… ;-=
[19:15:24] <davsclaus>     apache aries with the gazillion different
version numbers scares me
[19:15:39] <davsclaus>     i rather like that 2.10.3 all components has
tested and works together
[19:15:42] <splatch>     ok, lets back to api, component releases is
organization thing, not critical
[19:15:49] <davsclaus>     and don't mind 2.10.4 has a component with the
code base unchanged since 2.10.3
[19:15:51] <cschneid1>     davsclaus: Yes .. and it almost stopped releases
at aries as they did not even manage it themselves
[19:15:52] <davsclaus>     but its also released
[19:16:11]      olamy ( joined the channel.
[19:16:17] <davsclaus>     cschneid1 yeah i had to choose between
aries-proxy 1.1 aries-util 1.x? aries-xxx ?
[19:16:27] <davsclaus>     don't really know what works together etc
[19:16:28]      gnodet ( left
IRC. (gnodet)
[19:17:13]      iocanel ( joined the
[19:17:18] <cmueller>     I think the versioning topic has not to be done
in Camel 3.0
[19:17:19] <cschneid1>     So about the api .. what should a small api for
camel contain?
[19:17:25] <davsclaus>     cschneid1 about the routing engine, it goes a
bit hand-in-hand with the error handlers + interceptors + cross cutting
concerns being woven into each of the routes
[19:17:36] <cschneid1>     yes
[19:17:38] <davsclaus>     we need to take that out, so we have a 1:1 model
vs runtime
[19:17:45] <cschneid1>     +1
[19:17:46] <cmueller>     let's move it to Camel 3.x and MAY discuss it
later again after we have Camel 3.0
[19:17:50] <davsclaus>     then the routing engine can decide at runtime to
trigger onException or .to in the route
[19:17:53] <davsclaus>     e.g. what to call next
[19:18:06] <davsclaus>     there is sort of ready for doing that - the
[19:18:18] <davsclaus>     was intended back years ago for the place to
decide that
[19:18:42] <cschneid1>     davsclaus: The only thing is that I think we
first need to create a simpler api before we can start the routing engine
[19:18:44] <davsclaus>     but due that model not 1:1 it was not possible
to do in due time back then
[19:18:58]      szhem (~ left IRC. (szhem)
[19:19:19] <davsclaus>     simpler api from which pov ? end-users /
component developers / camel itself?
[19:19:35] <davsclaus>     the routing engine basically just has
[19:19:38] <davsclaus>     and AsyncProcessor
[19:19:42] <cschneid1>     from my pov mainly component designers
[19:19:46] <cmueller>     first of all, we need an API
[19:19:47] <davsclaus>     e.g. the latter is a bit more complicated
[19:20:01] <cschneid1>     will be off as I have to exit train
[19:20:04]      cschneid1 (~cschneid@ left IRC. (cschneid1)
[19:20:05] <davsclaus>     the api is the root package + spi
[19:20:19] <davsclaus>     but yeah it now has many exception classes / etc
[19:20:31] <splatch>     davsclaus: yes, however API should have minimal
set of classes
[19:20:36] <davsclaus>     so i guess you want a component developer api
that has the 10-20 interfaces needed?
[19:20:47] <cmueller>     yes
[19:20:47]      szhem (~ joined the
[19:20:49] <splatch>     davsclaus: for me DefaultErrorHandler is not part
of API, it's part of core or default implementation
[19:20:58]      cschneid3 (
joined the channel.
[19:21:04] <davsclaus>     yeah there is a spi.ErrorHandler AFAIR
[19:21:19] <cschneid3>     Back on phone
[19:21:24] <davsclaus>     and you can chose to use which error handler in
the DSL
[19:21:36] <davsclaus>     so that has an API
[19:21:52] <splatch>     davsclaus: but API is not aware of DSL
[19:22:01] <splatch>     at least it shouldn't be, component has nothing to
do with DSL
[19:22:23] <davsclaus>     the error handler is part of camel routing
[19:22:32] <davsclaus>     and you normally would use the DSL to define
[19:22:41] <cschneid3>     But what would the smallest camel api contain
[19:22:46] <davsclaus>     component developers do not use the error
handler api when writing components
[19:22:47] <davsclaus>     they use
[19:22:48] <davsclaus>     Exchange
[19:22:50] <davsclaus>     Consumer
[19:22:51] <davsclaus>     Producer
[19:22:53] <davsclaus>     etc
[19:23:05] <splatch>     davsclaus: agreed!
[19:23:12] <cschneid3>     Message
[19:23:13] <cschneid3>     Yes
[19:23:33] <davsclaus>     the root package (we could possible move some
classes or have a sub package for exceptions or what makes sense)
[19:23:41]      dottyo ( joined the channel.
[19:23:41] <davsclaus>     and some common classes from spi
[19:24:14] <cschneid3>     I tried to refactor like this
[19:24:16] <davsclaus>
[19:25:03] <cschneid3>     The problem is that at some point the api
references half the core
[19:25:50] <davsclaus>     as osgi don't like splitter packages we can't
cut a camel-component-api that has a selected number of apis ?
[19:25:51] <cschneid3>     That is why i propose to create a new
independent small api
[19:26:18] <cschneid3>     Completely separated from core
[19:26:33] <cschneid3>     And then a bridge to core
[19:27:13] <cschneid3>     Basically the idea came from guillaume at
[19:27:33] <davsclaus>     though we have 130+ components now and keep
growing, so our end users can fairly easy figure out to create components
[19:27:44] <davsclaus>     so the current api works
[19:28:02] <splatch>     at least for component developers ;-)
[19:28:04] <davsclaus>     but if we can rewind 5 years then for sure it
may have been nice to create a small api
[19:28:14] <davsclaus>     yeah and thats the main "customers"
[19:29:02] <cschneid3>     Not really
[19:29:02] <cschneid3>     There is no real api
[19:29:14] <davsclaus>     there is an api
[19:29:22] <davsclaus>     its just that there is 30 exceptions in the root
package also
[19:29:29] <davsclaus>     and you may only need occaptuonally to use one
of them
[19:29:37]      mr_smith (~mr_smith@ joined the channel.
[19:29:42] <cschneid3>     And references to impls
[19:29:45] <davsclaus>     or the api package have X other interfaces you
most likely not need to use for normal components
[19:30:05]      olamy ( left IRC. (olamy)
[19:30:21] <cschneid3>     Yes that is why i think we hce to start clean
[19:30:36] <cmueller>     I think it's easy to agree that the exceptions
should go into "org.apache.camel.exception"?
[19:30:51] <davsclaus>     well if we can create a independent module as
you say and "bridge" it or what it takes
[19:31:04] <davsclaus>     then that seems like a gentle and non disruptive
[19:31:10] <cmueller>     of course
[19:31:25] <davsclaus>     and people can ad-hoc use the new api for new
[19:31:31] <davsclaus>     and use the old for existing etc
[19:31:35] <cschneid3>     Yea
[19:31:54] <davsclaus>     it would be a disaster for camel if 3.0 cannot
use existing 2.x components etc
[19:31:55] <cmueller>     And I would like to have a "org.apache.camel.api"
package which makes clear THIS IS OUR API
[19:32:02] <cschneid3>     The idea is to bridge to the mainly unchanged
[19:32:08] <davsclaus>     yes there may be a few changes that may require
changes but for the overall majority it should just works
[19:32:34] <cschneid3>     Then we move all components to the new api
[19:32:46] <cschneid3>     After that we are free to change core
[19:33:07] <davsclaus>     yeah sure a separate camel-api would be nice,
and a camel-core etc - if we can rewind 5 years then James most likely
would have created Camel that way
[19:33:09] <cschneid3>     And not break components
[19:33:48] <davsclaus>     if we don't have to worry about osgi split
[19:33:56] <davsclaus>     then we could have an api with the same package
names as today
[19:34:13] <davsclaus>     we can't really move the root package and move
Processor / Exchange / Message to another package
[19:34:17] <splatch>     davsclaus: from other hand a breaking changes in
3.0 will definitelly clean up number of unsupported components in 2.x
[19:34:20] <cmueller>     Yes, I think we have now the possibility to lern
from our misstakes and build a better - not new - Camel
[19:34:55] <davsclaus>     yeah better NOT new - e.g. ppl expect this to
still lbe Camel and use as is
[19:35:59] <davsclaus>     splatch if the breaking is compile breaking then
we need to fix it ourselves, but yeah we should also look into
[19:36:02] <cschneid3>     I think we can move to .api
[19:36:09] <davsclaus>     at components which we should drtop
[19:36:40] <cschneid3>     And then move one component after the other
[19:36:57] <davsclaus>     its not just the components we offer out of the
box, they can all be changed by us
[19:36:57] <splatch>     davsclaus: there are terrible holes which was
discussed as part of 2.x duscussions, like lack of URI/configuration
verification before running component, however it may be done after
cleaning up API module
[19:37:00] <davsclaus>     its END USERs
[19:37:16] <davsclaus>     if they must migrate all their stuff that is hard
[19:37:39] <cschneid3>     We will not be able to avoid that in the end
[19:37:51] <davsclaus>     then its maybe not a good idea
[19:38:00] <cschneid3>     But we cam provide a transition
[19:38:04] <davsclaus>     the end users is not screaming for api changes
and whatnot
[19:38:13] <splatch>     I don't live in perfect world, when I change
Jackson version I am aware that I will have to spend some time to align my
[19:38:13] <davsclaus>     they can build camel apps + custom components
[19:38:18] <cschneid3>     The end user wants features
[19:38:31] <davsclaus>     stability = they want more
[19:38:45] <cschneid3>     And we already loose the ability to provide new
[19:38:45] <davsclaus>     they can always hack up new camel components to
integrate with X new stuff
[19:38:59] <splatch>     the same should be true for camel, not every
release, but major releases are introduced to have beaking changes as
semver says
[19:39:02] <davsclaus>     camel has added a ton of functionality over the
[19:39:08] <davsclaus>     more than mule / SI / and all the others
[19:39:09] <cschneid3>     Almost no one touches core andmore
[19:39:10] <cmueller>     yes, but @Deprecated the old code in core
[19:39:13] <cschneid3>     Anymore
[19:39:19] <cmueller>     link to .api
[19:39:29] <davsclaus>     stability in the core is a VERY good thing
[19:39:38] <cschneid3>     Yes
[19:39:42] <cmueller>     should be easy for components developers to
[19:39:51] <cschneid3>     But it leads to many quirks
[19:39:52] <cmueller>     in one or two releases
[19:39:59] <splatch>     davsclaus: none from contributors can touch core
without loosing his hands! thats bad!
[19:40:19] <cschneid3>     Yes
[19:40:21] <davsclaus>     what camel does is not easy
[19:40:44] <splatch>     it is easy, it's sometimes just done in
overcomplicated way
[19:40:52] <cschneid3>     And current core maked it even more difficult
[19:42:29] <cmueller>     May be I can try someting in a sanbox what I
think we could/should do
[19:42:50] <cschneid3>     sounds good
[19:42:54] <cmueller>     than it's easier to discuss something concrete
[19:43:18] <cmueller>     and we get an idea whether it works in the way we
think it will work
[19:43:42] <cmueller>     only moving classes/interfaces around
[19:43:51] <cmueller>     nothing special
[19:44:17] <cmueller>     next week is ApacheCon
[19:44:33] <cmueller>     Not sure I will find some time
[19:44:44] <cmueller>     but I will try my best
[19:45:28] <cschneid3>     Will you create a new api or refactor core?
[19:45:59] <cmueller>     I will start with small steps :-)
[19:46:05]      gnodet (
joined the channel.
[19:46:16] <cmueller>     moving exceptions to a sub package
[19:46:27] <cschneid3>     Ok
[19:46:28] <cmueller>     moving interfaces from core to api
[19:46:40] <cmueller>     provide a bridge in core
[19:47:00] <cschneid3>     Can you try to make the api standalone?
[19:47:02] <cmueller>     and annotate it with @Deprecated
[19:47:25] <cmueller>     do you mean in a separate bundle?
[19:47:31] <cschneid3>     Dont care for the bridge at the start . It is a
lot of work
[19:47:59] <cschneid3>     I mean the api may not reference anything
outside api
[19:48:17] <cmueller>     yes, of course
[19:48:27] <cmueller>     may execptions
[19:48:28] <cschneid3>     You can check with s101
[19:48:35] <cmueller>     ???
[19:48:45] <cschneid3>     Structure 101
[19:48:58] <cschneid3>     We can get free licenses for camel
[19:49:44] <cmueller>     for all the stupits guys like me:
[19:49:44] <cschneid3>     I can organize this if anyone needs a license
[19:49:47] <davsclaus>     have fun in portland
[19:49:48] <cmueller>     ;-)
[19:50:22] <cschneid3>     I will not be at apachecon
[19:50:23] <cmueller>     thanks, somebody else in Portland?
[19:51:04] <cschneid3>     Some from talend like dan and hadrian
[19:51:34] <cmueller>     ok, cool...
[19:51:43] <cmueller>     some RedHat guys too?
[19:52:38] <davsclaus>     some of us are going to devconf later this week
[19:52:40] <splatch>     not me :-)
[19:52:57] <davsclaus>     not sure if any/who goes to portland
[19:52:58] <splatch>     yup, will be in Czech on Friday
[19:53:03] <davsclaus>     its a long travel for EMEA guys
[19:53:12] <davsclaus>     and even for US too
[19:53:22] <davsclaus>     e.g. most of our fuse eng is easy cost
[19:53:38] <cmueller>     yes, but I like too meet you guys
[19:54:01] <davsclaus>     well new company, and more ppl to fight for the
travel budget :(
[19:54:16] <splatch>     cmueller: come to Brno and meet us, then go to
Portland :D
[19:54:32] <davsclaus>     the beers should be cheap in CZ
[19:54:39] <cmueller>     :-)
[19:54:43] <davsclaus>     was there 15+ years ago or there abouts
[19:54:58] <davsclaus>     0.5 euro for a beer back then at the bars
[19:55:13] <cmueller>     sounds good
[19:55:26] <cmueller>     but too late for the invitation
[19:55:32] <cmueller>     may be the next time
[19:56:21] <cmueller>     Ok, something else guys we should discuss today?
[19:56:37] <davsclaus>     yeah hopefully i find my way to apache con EU
some day - especially if its at a football statium
[19:56:51] <cmueller>     otherwise I will prepare something on GitHub for
the next IRC session
[19:57:10] <davsclaus>     well camel 2.11 needs to get out of the door
[19:57:11] <cmueller>     like last year
[19:57:25]      gnodet ( left
IRC. (gnodet)
[19:57:25] <cmueller>     what's about Karaf 2.3.1?
[19:57:26] <davsclaus>     to pave the way for trunk being 3.0
[19:57:40] <davsclaus>     yeah didn't hear news about 2.3.1 recently
[19:57:45] <davsclaus>     something about an aries release
[19:57:46] <cmueller>     do the still wait for Aries
[19:57:51] <davsclaus>     but the #karaf guys knows
[19:57:52] <cmueller>     ok
[19:58:13] <davsclaus>     and most of us will be traveling so i guess
camel 2.11 is in march
[19:58:26] <davsclaus>     and maybe we can get a new bundle release as
some of the features requires that
[19:59:13] <cmueller>     ok, will check the Karaf mailing list later
[19:59:14] <davsclaus>     of for camel 3.0 we may consider a jmx naming
[19:59:29] <davsclaus>     i was told the mmx name for camel context has "
" as the only mbean
[19:59:32] <davsclaus>     would be nice to avoid that
[19:59:38] <davsclaus>     just a tiny issue
[19:59:51] <davsclaus>     but 3rd party mmx tooling kinda dislike that
[19:59:59] <cmueller>     ahh, ok
[20:00:08] <davsclaus>     and did we talk about dropping java6 for camel 3
[20:00:12] <davsclaus>     i kinda think its a no brainer
[20:00:23] <davsclaus>     e.g. require 1.7 as the minimum version
[20:00:37] <cmueller>     yes we talked about this
[20:00:41]      iocanel ( left IRC.
("Computer has gone to sleep.")
[20:00:53] <davsclaus>     and there is the "view" code in camel-core that
can be moved out of the core into camel-view
[20:00:56] <davsclaus>     or dropped all together
[20:00:59] <cmueller>     if I remember right, nobody complains
[20:01:04] <davsclaus>     i think i put that up on the ideas page
[20:01:44] <cmueller>     than we cannot forget it...
[20:01:53] <cmueller>     I think we can remove it
[20:02:06] <cmueller>     it's about the dot thing?
[20:02:23] <davsclaus>     yeah its not maintained  + used anymore
[20:02:40] <davsclaus>     and not needed to be in the core
[20:02:44] <cmueller>     yes, +1 to remove it
[20:03:00] <davsclaus>     there is plenty of code to maintain already
[20:03:08] <cmueller>     yes
[20:03:17] <cmueller>     I like to remove code ;-)
[20:03:48]      cschneid3 (
left IRC. (Ping timeout: 20 seconds)
[20:03:54] <cmueller>     ok, I have to leave
[20:04:07] <cmueller>     have a nice evening
[20:04:25] <cmueller>     bye bye


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message