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