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/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:
http://camel.apache.org/camel-30-ideas.html
[19:01:20] <cmueller> and our road map here:
http://camel.apache.org/camel-30-roadmap.html
[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
mentioned
[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
compatible
[19:07:15] <cschneid1> Yes .. that would mean we can do no bigger
changes
[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
classes
[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 (~
mira...@broadband-178-140-61-178.nationalcablenetworks.ru) joined the
channel.
[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
here
[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 mails
[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
individually
[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
component
[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 (~ol...@52.255.88.79.rev.sfr.net) 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 (~gno...@ven14-2-82-235-193-35.fbx.proxad.net)
left IRC. (gnodet)
[19:17:13] iocanel (~text...@athedsl-88751.home.otenet.gr) joined
the channel.
[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
DefaultChannel
[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
changes
[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 (~
mira...@broadband-178-140-61-178.nationalcablenetworks.ru) 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
org.apache.camel.Processor
[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@88.128.80.12) 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 (~
mira...@broadband-178-140-61-178.nationalcablenetworks.ru) joined the
channel.
[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 (~cschn...@tmo-110-215.customers.d1-online.com)
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
routes
[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 (~webc...@irc.codehaus.org) 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>
http://camel.apache.org/maven/current/camel-core/apidocs/index.html
[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
apachecon
[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@69.80.98.133) 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 (~ol...@52.255.88.79.rev.sfr.net) 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 way
[19:31:10] <cmueller> of course
[19:31:25] <davsclaus> and people can ad-hoc use the new api for new
components
[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
core
[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
packages
[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
code
[19:38:13] <davsclaus> they can build camel apps + custom components
easily
[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
features
[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
years
[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
migrate
[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 (~gno...@ven14-2-82-235-193-35.fbx.proxad.net)
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:
http://structure101.com/products/
[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 (~gno...@ven14-2-82-235-193-35.fbx.proxad.net)
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
today...
[19:59:14] <davsclaus> of for camel 3.0 we may consider a jmx naming
change
[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
"diff"
[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 (~text...@athedsl-88751.home.otenet.gr) 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 (~cschn...@tmo-110-215.customers.d1-online.com)
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
--
