cschneider, what you basically suggest is to rewrite camel, and create a layer to bridge the old to the new camel. Before going this way, I'd like to understand why is that necessary (but the fact that it's cleaner, which in itself is nice, but not sufficient to me).
I do agree that the model and main dsl is mixed together, though this does not prevent writing other DSLs or inventing a new one for java in a different module. In addition, it's more a fluent api than a dsl, so if you want to remove this api, you still need a way to create the camel model with routes, processors, endpoints and all. So imho, trying to remove the java dsl from the model will just lead to 2 different things, one with a nice api but ugly to manipulate and another one which defines wrappers around the model with a nicer api. I'm not really sure what the real gain would be, it may even lead to a more heavyweight camel at the end. For the xml dsl, one thing to remember is that it's just a few annotations on the existing model, so removing it will mean having a duplicate object model generated from an xsd and a translation : it's not more lightweight either. Also if we end up with different intermediate model for the xml, it needs to be kept in sync both ways, as xml is the usual serialization format for the model. It's even totally doable to write a new xml dsl for 2.x if needed because the existing one is found too limitating. I'm sure it's also possible to write another java dsl on top of 2.x too. So at the end, I'm not buying the DSL argument at all. I don't think a 5 man-year effort should be started for no purposes than just cleaning things. I think it will end up as Karaf 3 which has now been started 2 years ago and not released yet. So I'd like to understand why such a big change is *necessary*. The problem in rewriting a new api is that it will take a very long time for users and for other projects to switch. If they don't see the need for switching, it will delay even more. In addition, and that's what has happened for Karaf, if the developper community is not convinced that the new major version is needed, you'll reduce the workload to work on the 3.x branch and it will be even worse. So while having a thiner camel-core would be nice, and having a cleaner api would be nice too, I certainly don't want to go there at all costs. The work that has been done with the introduction of the ModelCamelContext to break the dependency between the api and the model is really good, and I really think we should go in that direction. If we further add a ModelRouteContext, I think that would definitely split the api from the model. More generally, I think we should really go this way: i.e. refactor the api step by step on 2.x / trunk to clean things, eventually split if possible and when the 2.x contains both the deprecated api + the new one, create a 3.x branch and remove the deprecated apis. This would ensure #1 no pause in development and bringing new stuff to users by working on a single branch #2 that 2.x is fully compatible with 3.x #3 that users have ample time to get rid of the use of deprecated apis On Wed, Feb 20, 2013 at 8:32 AM, Christian Schneider < ch...@die-schneider.net> wrote: > Hi Christian, > > what you did is similar to what I did when I moved classes. It is a way to > stay compatible while moving some classes. > The problem is that the kind of refactorings you can do with this aproach > are quite limited. > > What I had in mind is a much bigger change. > > Basically the idea is to have new api in e.g. org.apache.camel.api that is > in its own jar and really as small and simple as possible. > > Then we have a bridge module that translates for example an exchange > expressed by the new api into an exchange of the current camel-core. > > So a component developer would only depend on the new camel-api jar. At > runtime the bridge would allow to use this model with the current > camel-core. So we have a nice transition. > > In the end we would then provide a new camel-core that only depends on the > new api and can be completely different to the current camel core. So at > least for component developers we would have > a nice transition and a much simpler model in the end. > > This aproach of course does not cover end users that use the camel dsl and > for example also write processors. Perhaps we also have a good idea for > these but it would be much more difficult to keep this api stable. > In any case one question is if the component API is already sufficient for > end users too or if they need a bigger api. > > In any case the dsl should be separate from the inner api. Perhaps we > could even have a camel core that does not even contain the dsl. So camel > could be used in a broader range of situations than now. For example > Hadrian told me about a customer who would like to use camel components but > not the dsl and has real time requirements. So this customer could write a > real time core for standard camel components and would not have to > implement the whole dsl. > > Spearation of core and dsl would also allow to have separate DSLs at the > same time. So we could provide a DSL that looks mostly like camel 2 and a > new DSL for camel 3 that is largely different. > > Christian > > Am 19.02.2013 23:31, schrieb Christian Müller: > > Christian, Claus, others... >> could you please have a look at the following commit: >> https://github.com/muellerc/**camel/commit/** >> fd9bb64586c1d082e4169cf08831da**9c2b6afccb<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<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<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 (~ >>> Miranda@broadband-178-140-61-**178.nationalcablenetworks.ru<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<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 >>> (~gnodet@ven14-2-82-235-193-**35.fbx.proxad.net<gno...@ven14-2-82-235-193-35.fbx.proxad.net> >>> ) >>> left IRC. (gnodet) >>> [19:17:13] iocanel >>> (~text...@athedsl-88751.home.**otenet.gr<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 (~ >>> Miranda@broadband-178-140-61-**178.nationalcablenetworks.ru<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 (~ >>> Miranda@broadband-178-140-61-**178.nationalcablenetworks.ru<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 (~cschneid@tmo-110-215.** >>> customers.d1-online.com <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<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<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 >>> (~gnodet@ven14-2-82-235-193-**35.fbx.proxad.net<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/ <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 >>> (~gnodet@ven14-2-82-235-193-**35.fbx.proxad.net<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<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 (~cschneid@tmo-110-215.** >>> customers.d1-online.com <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 >>> >>> -- >>> >>> >>> >> -- >> >> > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
