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:
01/29/2013 7:00PM - 8:00PM CET - DISCUSSING THE CAMEL 3.0 ROAD MAP [18:58:31] <cmueller> In the next hour I would like to discuss which ideas from http://camel.apache.org/camel-30-ideas.html we should move to http://camel.apache.org/camel-30-roadmap.html and do before Camel 3.0, in Camel 3.0 and after Camel 3.0 [18:59:01] <cmueller> I will post this discussion afterwards to the dev@camel mailing list [19:00:08] <cmueller> so that all users have the possibility to express his/her minds [19:00:37] gnodet (~gno...@ven14-2-82-235-193-35.fbx.proxad.net) left IRC. (gnodet) [19:00:54] DRaCuLa (~k...@088156094246.wroclaw.vectranet.pl) joined the channel. [19:01:30] <cmueller> if there is no objection in the next say 72 hours, we will go ahead [19:03:02] <cmueller> The first thing I would like to do is removing all ideas which are already implemented (in Camel 2.9, 2.10, 2.11) [19:04:59] <cmueller> We also discussed the Camel Web console in this thread http://camel.465427.n5.nabble.com/DISCUSS-CAMEL-3-0-Does-camel-need-a-web-console-td5726280.html [19:05:30] iocanel (~text...@athedsl-4509136.home.otenet.gr) left IRC. ("Computer has gone to sleep.") [19:05:50] <cmueller> And for me it looks like we have an consensus to remove it [19:07:17] <cmueller> This means we can remove it from the Camel 3.0 ideas page or we add a comment that we do not implement/work on this idea [19:08:31] <cmueller> I starte already working on the "More load tests" idea [19:09:11] <cmueller> I think this should be done before Camel 3.0 [19:09:59] <cmueller> so that we can measure the performance of Camel 3.0 compared with Camel 2.x [19:11:50] <cmueller> the target version for tis cooresponding JIRA ticket is already Camel 2.12 https://issues.apache.org/jira/browse/CAMEL-5918 [19:13:07] <cmueller> Another thing we should do before Camel 3.0 is "Improve the test api for testing components" [19:13:33] iocanel (~text...@athedsl-4509136.home.otenet.gr) joined the channel. [19:14:06] <tjs> +1 on removing the console [19:14:41] <cmueller> Our Jenkins build need almost 2 hours for building the dist [19:15:07] <cmueller> Almost 3 hours if we also run the OSGI tests [19:16:32] <cmueller> To test a component, endpoint, producer, consumer, processor, Type Converter, Data Format, … we do not really have to set up and execute a Camel route [19:17:04] <cmueller> this could be a simple (and fast) JUnit test [19:17:47] rajdavies (~ text...@host86-161-249-129.range86-161.btcentralplus.com) left IRC. ("Textual IRC Client: www.textualapp.com") [19:19:10] <cmueller> we may need some syntactic sugar in a say new BasicCamelTestSupport [19:19:56] <cmueller> Of course we need some test which make sure our routing engine works [19:20:21] <cmueller> but we do not have to test it for each component again... [19:21:10] <cmueller> and faster unit tests will bring us a quicker development cycle [19:21:48] <cmueller> and less dependencies to the things we may break in Camel 3.0 [19:23:15] scranton (~scran...@c-24-128-50-227.hsd1.ma.comcast.net) joined the channel. [19:25:01] olamy (~ol...@38.55.0.93.rev.sfr.net) left IRC. (olamy) [19:26:52] boday (~bo...@99-120-99-13.lightspeed.sndgca.sbcglobal.net) left IRC. (Ping timeout: 20 seconds) [19:27:32] <cmueller> These are the only two ideas which should be done before Camel 3.0 [19:28:52] <cmueller> I prefere a shorter release cyclus for Camel 2.12 so we can start earlier with developing Camel 3.0 [19:30:36] <cmueller> What we have to do in Camel 3.0 is "Split camel-core into multiple parts" [19:31:26] rbalent (~rbal...@nat-pool-brq-t.redhat.com) left IRC. ("May the Force be with you") [19:31:42] iocanel (~text...@athedsl-4509136.home.otenet.gr) left IRC. ("Computer has gone to sleep.") [19:33:58] <cmueller> this will break some API's and has to be done in Camel 3.0 [19:36:19] <hadrian> cmueller: missed the beginning [19:36:57] <cmueller> no issue - it's a monolog until now… ;-) [19:37:43] <hadrian> cmueller: for testing we need more than one Basic...TestSupport [19:38:05] <hadrian> we need Support test classes for each aspect of camel we want to test [19:38:09] <hadrian> i already started on that [19:38:34] <hadrian> since there was no argument on the ideas page for a good while, that could be moved to the roadmap page [19:38:43] gmazza (~gma...@pool-74-96-59-92.washdc.east.verizon.net) joined the channel. [19:38:50] <cmueller> do you mean something like CamelComponentTestSupport, CamelEndpointTestSupport, ...? [19:38:54] <hadrian> i think there was no argument on the api splitting either [19:39:16] <hadrian> i can champion that as well, plus i have concrete ideas how to do it [19:39:29] <cmueller> cool [19:39:46] <cmueller> But I hope we will also get some more champions [19:39:47] <hadrian> cmueller: +1 on removing the done stuff from the ideas page [19:39:59] <hadrian> i left it for reference, but needs to be cleaned up [19:40:13] iocanel (~text...@athedsl-4509136.home.otenet.gr) joined the channel. [19:40:16] <hadrian> obvious stuff like "removing @deprecated" shouldn't even be there [19:40:33] <cmueller> Year, I was also thinking about this [19:40:34] <hadrian> no need to make the agenda sound longer and more important by adding useless tasks [19:40:46] <hadrian> there should be only the stuff that requires some discussion and agreement [19:41:08] <hadrian> the storage stuff should be moved near the top [19:41:25] <hadrian> i had to look in the change history to see christian ohr's comment [19:41:37] <cmueller> I was thinking about which idea will (may) the API [19:41:37] <hadrian> actually I volunteer christian ohr as a champion :) [19:41:51] gnodet (~gno...@ven14-2-82-235-193-35.fbx.proxad.net) joined the channel. [19:41:53] <hadrian> i think it's ok to have non committers as champions if they are interested to help out [19:41:57] <hadrian> or have a steak in the changes [19:42:05] <cmueller> will may break the API and should be done in Camel 3.0 [19:42:24] <hadrian> well, i don't think much of the api will be broken [19:42:35] <hadrian> most of what we have is good [19:42:45] <hadrian> there are some (like the CamelContext that are not good) [19:42:58] <hadrian> but we can still support and deprecate that class [19:43:05] <cmueller> +1 for none committers as champion [19:43:09] <hadrian> keep in mind that we have 2 kinds of users [19:43:28] <hadrian> the 'real' users who use camel as a product [19:43:43] <hadrian> and developers who use it as a framework (mostly component developers) [19:43:59] <hadrian> it's important to break as little as possible for the former [19:44:09] <hadrian> it is acceptable to break some api for the latter [19:44:38] iocanel (~text...@athedsl-4509136.home.otenet.gr) left IRC. (Ping timeout: 20 seconds) [19:44:41] <hadrian> i was also thinking, but don't have a proposal yet, not sure what would work [19:44:55] <hadrian> about how to handle the growing number of components [19:45:05] <hadrian> and how to manage their maintenance [19:45:20] <hadrian> a components supbroject? [19:45:44] <hadrian> i don't like the tight coupling between the component development and the core [19:45:48] <hadrian> but not sure what would work [19:46:13] <hadrian> we have plenty of examples to learn from, from httpd/maven/smx/etc [19:46:41] <hadrian> but really don't know if a components sub-project (released more often) would work [19:46:45] <cmueller> You mean only releasing a new component version if we really touch it? [19:46:50] <hadrian> thoughts? [19:46:59] <hadrian> not really that granular, but yes [19:47:15] <hadrian> or maybe that granular, who knows [19:47:24] <joed> That would rock. [19:47:40] hadrian just volunteered joed as a champion [19:47:40] <joed> Much more flexibility on upgrading/bug fixing [19:47:54] <cmueller> and a version hell ;-) [19:48:03] <hadrian> correct, and i don't think voting we'll ever be an issue, plenty of pmc members around to help out [19:48:15] <hadrian> releasing one component should be absolutely trivial [19:48:31] <hadrian> cmueller: and version hell, correct :) [19:48:42] <hadrian> so again, i don't know what would work [19:49:05] iocanel (~text...@athedsl-4498726.home.otenet.gr) joined the channel. [19:49:07] <cmueller> We should put it on the list and think about it [19:49:18] <hadrian> the version hell may not be that hot if we enforce some convention [19:49:21] <cmueller> I see pro and con [19:49:27] <hadrian> like use the same major.minor as the core [19:49:38] <hadrian> for the patch digit, mix and match... [19:49:41] <hadrian> dunno [19:50:01] <cmueller> I had the same in my mind [19:50:13] geaaru (~ gea...@host170-152-static.43-88-b.business.telecomitalia.it) left IRC. ("Leaving") [19:50:36] <cmueller> Can you put it on the idea page? [19:50:54] <cmueller> and mention joed as champion? ;) [19:50:56] <hadrian> cmueller: you were talking to joed I would assume :) [19:51:27] <hadrian> joed: hellooo :) [19:51:30] iocanel (~text...@athedsl-4498726.home.otenet.gr) left IRC. (Ping timeout: 20 seconds) [19:51:51] <hadrian> cmueller: should the dsl be in a separate jar? [19:51:55] iocanel (~text...@athedsl-4498726.home.otenet.gr) joined the channel. [19:51:56] <hadrian> i'd say yes [19:51:57] <cmueller> joed: hellooo = yes? [19:52:07] <cmueller> ;) [19:52:20] <hadrian> cmueller: yes, i'll put it [19:52:43] <cmueller> What would be the benefit? [19:52:46] <hadrian> i started to dislike more and more the fact that we have no flexibility in how we build routes [19:52:56] <hadrian> ah, there are many benefits [19:53:00] <hadrian> this is just my rationale [19:53:21] <joed> Whut? Trying to hide here. [19:53:39] <hadrian> joed: you're the champion for the micro releases :) [19:53:52] <joed> I can see it very beneficial in getting something like JMS / CXF patched without a whole release... [19:53:54] <hadrian> we're waiting to see your proposal on the ideas page [19:54:00] <joed> Hahaha [19:54:11] <hadrian> joed: we got it, you got my support +1, etc [19:54:22] joed trips hadrian [19:54:54] <hadrian> joed: cmueller will post this on the public mailing list [19:54:57] <cmueller> one of you will make it… :) [19:55:01] <hadrian> now I have proof, i'll sue you [19:55:26] joed trips cmueller too [19:55:29] <joed> Hahaha [19:55:42] hadrian slaps both cmueller and joed with a fish [19:55:48] <cmueller> ok, I will put it on the page with my ideas [19:55:49] <hadrian> back to work guys [19:56:08] <hadrian> so I think we need some flexibility on how we build the routes [19:56:19] <hadrian> right now there's only one way [19:56:27] <cmueller> true [19:56:38] cibsen (~cib...@78-72-73-107-no33.tbcn.telia.com) joined the channel. [19:56:44] <hadrian> and the dsl, btw smells like the fish I slapped you with :) [19:57:00] <hadrian> you have a hodge podge of high level and low level things [19:57:17] <joed> and xml. [19:57:26] <hadrian> and one may argue that setHeader and setBody are not eips (as defined in the book) [19:57:27] <cmueller> but only having a separate bundle/jar doesn't solve the problem [19:57:36] <cmueller> for the dsl [19:57:45] <hadrian> so .transform(body()... or .transform(header()... [19:57:49] <hadrian> may be a better way, etc [19:58:03] <hadrian> ah, of course not, but it's a prerequisite :) [19:58:45] <cmueller> why? [19:59:07] <hadrian> because you don't need the dsl at runtime at all [19:59:15] <hadrian> i may want to build my route manually [19:59:19] <cmueller> I think we need some "extension points" [19:59:24] <hadrian> neat, lean runtime [19:59:29] <hadrian> agree [19:59:49] <hadrian> so runtime and dsl don't quite belong together [19:59:54] <cmueller> however they will look like [20:00:04] <cmueller> ok, understood [20:00:21] <hadrian> cmueller: that doesn't mean that we won't have an uber-jar having both [20:00:38] <hadrian> we probably will and it'd be called camel-core [20:00:47] <hadrian> and look pretty much like 2.x [20:01:03] <hadrian> that's where we can maintain the back compat as well [20:01:08] <hadrian> makes sense? [20:01:12] <cmueller> yes [20:01:13] <hadrian> ... and time's up [20:01:17] <hadrian> :) [20:01:43] <cmueller> We have the idea "More flexible routes at runtime" [20:01:55] <cmueller> this match [20:02:17] <hadrian> yeah, need to work on it a bit [20:02:46] <hadrian> joed: thanks for volunteering :) [20:02:49] <cmueller> I also have to think about it [20:02:56] <cmueller> how it can work [20:03:04] <cmueller> hahaha [20:03:36] <cmueller> we need of course some more champions [20:03:38] <hadrian> cmueller: start by wiring processors manually, get the functionality you want [20:03:41] boday (~bo...@64-73-244-147.static-ip.telepacific.net) joined the channel. [20:03:54] <hadrian> and see how that route looks compared to the dsl generated one [20:03:58] <hadrian> you'll be surprised :) [20:04:22] <cmueller> I'm sooo lazy - do you have an example for me? ;) [20:04:55] <hadrian> i have to dig a bit, but sure, i'll send you a sample [20:05:01] <cmueller> thx [20:05:23] <hadrian> cool, made some progress today [20:05:28] <cmueller> yes [20:05:51] <hadrian> cmueller: can you ask christian ohr if he'd volunteer for champion? [20:05:52] <cmueller> I have to leave in a few minutes [20:05:57] <hadrian> you're in the same time zone [20:06:01] <cmueller> yes, please [20:06:11] <cmueller> I will do it [20:06:11] <hadrian> i meant you, not me :) [20:06:14] <hadrian> cool [20:06:23] <hadrian> so let's adjourn for today [20:06:26] <hadrian> thx [20:06:31] <cmueller> next week - same time? [20:06:37] <hadrian> sure, should work [20:06:44] <cmueller> or should we talk earlier? [20:06:54] <hadrian> and if you ping me, i won't miss the begining [20:07:23] <hadrian> either way, i am on this channel a lot [20:07:28] <hadrian> although mostly quiet [20:07:44] chirino (~ chir...@pool-71-180-128-149.tampfl.fios.verizon.net) joined the channel. [20:08:03] tjs (~t...@c-71-197-42-48.hsd1.fl.comcast.net) left IRC. ("Leaving...") [20:08:04] <cmueller> I know, but some more people and some more discussion here would be great [20:08:08] tjs (~t...@c-71-197-42-48.hsd1.fl.comcast.net) joined the channel. [20:08:55] <cmueller> ok, thanks guys [20:08:55] tjs (~t...@c-71-197-42-48.hsd1.fl.comcast.net) left IRC. (Client closed connection) [20:08:59] <hadrian> gotta run, take care [20:09:06] <cmueller> I have to leave [20:09:22] <cmueller> will post it later to the dev@ list [20:09:35] <cmueller> by by --
