Christian, Claus, others... could you please have a look at the following commit: https://github.com/muellerc/camel/commit/fd9bb64586c1d082e4169cf08831da9c2b6afccb
This is my understanding of bridging the existing code to the new one. Do we have the same understanding? Of course I have to change the reference in Camel itself from org.apache.camel.VetoCamelContextStartException to org.apache.camel.api.exception.VetoCamelContextStartException... Best, Christian On Tue, Feb 19, 2013 at 9:57 PM, Christian Müller < christian.muel...@gmail.com> wrote: > 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 > > -- > > --
