Return-Path: X-Original-To: apmail-camel-dev-archive@www.apache.org Delivered-To: apmail-camel-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id F31F3D104 for ; Tue, 29 Jan 2013 19:14:44 +0000 (UTC) Received: (qmail 91092 invoked by uid 500); 29 Jan 2013 19:14:44 -0000 Delivered-To: apmail-camel-dev-archive@camel.apache.org Received: (qmail 91016 invoked by uid 500); 29 Jan 2013 19:14:44 -0000 Mailing-List: contact dev-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@camel.apache.org Delivered-To: mailing list dev@camel.apache.org Received: (qmail 91004 invoked by uid 99); 29 Jan 2013 19:14:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Jan 2013 19:14:44 +0000 X-ASF-Spam-Status: No, hits=2.8 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,URI_HEX X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of christian.mueller@gmail.com designates 209.85.219.53 as permitted sender) Received: from [209.85.219.53] (HELO mail-oa0-f53.google.com) (209.85.219.53) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Jan 2013 19:14:40 +0000 Received: by mail-oa0-f53.google.com with SMTP id l20so824126oag.26 for ; Tue, 29 Jan 2013 11:14:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=9DcXiw/oqCEcI68mYK3GitlK75oUj3rf9MZu6GTjMVM=; b=CDXtR8t0wg9lq20v74WDr30W1XxZWD3fpm+UW7dsPxEStp94fCaWfbZr/T5+jyySPt IEvS7o9BHhsWZDIsk4q/ZHn2cR5ySBf1Jy9Xlge7WA9+aXcK5nMBJRyJ7oVTJ+t3B5kH BM2vypZeZg5rl+GaySe8kJf/I8IE4KHBOuadqew+eWZb2kQZ+SEbnLw0IzgqE/1JXEiV y+tGWLanLVx/mBG2zMHsEsvwXlNlQHI68EFDbDDbGCpXFrocI67W6Xnpjn0HusjhvSMG Cex/AbJoTCPUV3N28CbLVRUp5w6nSvVnQhNcn0udGZZLLdFn1P4to7pJ2Y8P3gilEL+w SPPQ== MIME-Version: 1.0 X-Received: by 10.60.32.193 with SMTP id l1mr1548737oei.114.1359486859473; Tue, 29 Jan 2013 11:14:19 -0800 (PST) Received: by 10.182.114.103 with HTTP; Tue, 29 Jan 2013 11:14:19 -0800 (PST) Date: Tue, 29 Jan 2013 20:14:19 +0100 Message-ID: Subject: [DISCUSS CAMEL 3.0] weekly IRC chat at 01/29/2013 7:00PM - 8:00PM CET From: =?ISO-8859-1?Q?Christian_M=FCller?= To: dev@camel.apache.org Content-Type: multipart/alternative; boundary=e89a8fb1f6ca55f49d04d4723312 X-Virus-Checked: Checked by ClamAV on apache.org --e89a8fb1f6ca55f49d04d4723312 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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] 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] I will post this discussion afterwards to the dev@camel mailing list [19:00:08] so that all users have the possibility to express his/her minds [19:00:37] gnodet (~gnodet@ven14-2-82-235-193-35.fbx.proxad.net) left IRC. (gnodet) [19:00:54] DRaCuLa (~kso@088156094246.wroclaw.vectranet.pl) joined the channel. [19:01:30] if there is no objection in the next say 72 hours, we will go ahead [19:03:02] 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] 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-c= onsole-td5726280.html [19:05:30] iocanel (~textual@athedsl-4509136.home.otenet.gr) left IRC. ("Computer has gone to sleep.") [19:05:50] And for me it looks like we have an consensus to remove it [19:07:17] 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] I starte already working on the "More load tests" idea [19:09:11] I think this should be done before Camel 3.0 [19:09:59] so that we can measure the performance of Camel 3.0 compared with Camel 2.x [19:11:50] the target version for tis cooresponding JIRA ticket is already Camel 2.12 https://issues.apache.org/jira/browse/CAMEL-5918 [19:13:07] Another thing we should do before Camel 3.0 is "Improve the test api for testing components" [19:13:33] iocanel (~textual@athedsl-4509136.home.otenet.gr) joined the channel. [19:14:06] +1 on removing the console [19:14:41] Our Jenkins build need almost 2 hours for building the dist [19:15:07] Almost 3 hours if we also run the OSGI tests [19:16:32] To test a component, endpoint, producer, consumer, processor, Type Converter, Data Format, =85 we do not really have to set up and execute a Camel route [19:17:04] this could be a simple (and fast) JUnit test [19:17:47] rajdavies (~ textual@host86-161-249-129.range86-161.btcentralplus.com) left IRC. ("Textual IRC Client: www.textualapp.com") [19:19:10] we may need some syntactic sugar in a say new BasicCamelTestSupport [19:19:56] Of course we need some test which make sure our routing engine works [19:20:21] but we do not have to test it for each component again... [19:21:10] and faster unit tests will bring us a quicker development cycle [19:21:48] and less dependencies to the things we may break in Camel 3.0 [19:23:15] scranton (~scranton@c-24-128-50-227.hsd1.ma.comcast.net) joined the channel. [19:25:01] olamy (~olamy@38.55.0.93.rev.sfr.net) left IRC. (olamy) [19:26:52] boday (~boday@99-120-99-13.lightspeed.sndgca.sbcglobal.net) left IRC. (Ping timeout: 20 seconds) [19:27:32] These are the only two ideas which should be done before Camel 3.0 [19:28:52] I prefere a shorter release cyclus for Camel 2.12 so we can start earlier with developing Camel 3.0 [19:30:36] What we have to do in Camel 3.0 is "Split camel-core into multiple parts" [19:31:26] rbalent (~rbalent@nat-pool-brq-t.redhat.com) left IRC. ("May the Force be with you") [19:31:42] iocanel (~textual@athedsl-4509136.home.otenet.gr) left IRC. ("Computer has gone to sleep.") [19:33:58] this will break some API's and has to be done in Camel 3.0 [19:36:19] cmueller: missed the beginning [19:36:57] no issue - it's a monolog until now=85 ;-) [19:37:43] cmueller: for testing we need more than one Basic...TestSupport [19:38:05] we need Support test classes for each aspect of camel we want to test [19:38:09] i already started on that [19:38:34] 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 (~gmazza@pool-74-96-59-92.washdc.east.verizon.net) joined the channel. [19:38:50] do you mean something like CamelComponentTestSupport, CamelEndpointTestSupport, ...? [19:38:54] i think there was no argument on the api splitting either [19:39:16] i can champion that as well, plus i have concrete ideas how to do it [19:39:29] cool [19:39:46] But I hope we will also get some more champions [19:39:47] cmueller: +1 on removing the done stuff from the ideas page [19:39:59] i left it for reference, but needs to be cleaned u= p [19:40:13] iocanel (~textual@athedsl-4509136.home.otenet.gr) joined the channel. [19:40:16] obvious stuff like "removing @deprecated" shouldn't even be there [19:40:33] Year, I was also thinking about this [19:40:34] no need to make the agenda sound longer and more important by adding useless tasks [19:40:46] there should be only the stuff that requires some discussion and agreement [19:41:08] the storage stuff should be moved near the top [19:41:25] i had to look in the change history to see christian ohr's comment [19:41:37] I was thinking about which idea will (may) the AP= I [19:41:37] actually I volunteer christian ohr as a champion := ) [19:41:51] gnodet (~gnodet@ven14-2-82-235-193-35.fbx.proxad.net) joined the channel. [19:41:53] i think it's ok to have non committers as champions if they are interested to help out [19:41:57] or have a steak in the changes [19:42:05] will may break the API and should be done in Camel 3.0 [19:42:24] well, i don't think much of the api will be broken [19:42:35] most of what we have is good [19:42:45] there are some (like the CamelContext that are not good) [19:42:58] but we can still support and deprecate that class [19:43:05] +1 for none committers as champion [19:43:09] keep in mind that we have 2 kinds of users [19:43:28] the 'real' users who use camel as a product [19:43:43] and developers who use it as a framework (mostly component developers) [19:43:59] it's important to break as little as possible for the former [19:44:09] it is acceptable to break some api for the latter [19:44:38] iocanel (~textual@athedsl-4509136.home.otenet.gr) left IRC. (Ping timeout: 20 seconds) [19:44:41] i was also thinking, but don't have a proposal yet, not sure what would work [19:44:55] about how to handle the growing number of components [19:45:05] and how to manage their maintenance [19:45:20] a components supbroject? [19:45:44] i don't like the tight coupling between the component development and the core [19:45:48] but not sure what would work [19:46:13] we have plenty of examples to learn from, from httpd/maven/smx/etc [19:46:41] but really don't know if a components sub-project (released more often) would work [19:46:45] You mean only releasing a new component version if we really touch it? [19:46:50] thoughts? [19:46:59] not really that granular, but yes [19:47:15] or maybe that granular, who knows [19:47:24] That would rock. [19:47:40] hadrian just volunteered joed as a champion [19:47:40] Much more flexibility on upgrading/bug fixing [19:47:54] and a version hell ;-) [19:48:03] correct, and i don't think voting we'll ever be an issue, plenty of pmc members around to help out [19:48:15] releasing one component should be absolutely trivial [19:48:31] cmueller: and version hell, correct :) [19:48:42] so again, i don't know what would work [19:49:05] iocanel (~textual@athedsl-4498726.home.otenet.gr) joined the channel. [19:49:07] We should put it on the list and think about it [19:49:18] the version hell may not be that hot if we enforce some convention [19:49:21] I see pro and con [19:49:27] like use the same major.minor as the core [19:49:38] for the patch digit, mix and match... [19:49:41] dunno [19:50:01] I had the same in my mind [19:50:13] geaaru (~ geaaru@host170-152-static.43-88-b.business.telecomitalia.it) left IRC. ("Leaving") [19:50:36] Can you put it on the idea page? [19:50:54] and mention joed as champion? ;) [19:50:56] cmueller: you were talking to joed I would assume :) [19:51:27] joed: hellooo :) [19:51:30] iocanel (~textual@athedsl-4498726.home.otenet.gr) left IRC. (Ping timeout: 20 seconds) [19:51:51] cmueller: should the dsl be in a separate jar? [19:51:55] iocanel (~textual@athedsl-4498726.home.otenet.gr) joined the channel. [19:51:56] i'd say yes [19:51:57] joed: hellooo =3D yes? [19:52:07] ;) [19:52:20] cmueller: yes, i'll put it [19:52:43] What would be the benefit? [19:52:46] i started to dislike more and more the fact that we have no flexibility in how we build routes [19:52:56] ah, there are many benefits [19:53:00] this is just my rationale [19:53:21] Whut? Trying to hide here. [19:53:39] joed: you're the champion for the micro releases := ) [19:53:52] I can see it very beneficial in getting something like JMS / CXF patched without a whole release... [19:53:54] we're waiting to see your proposal on the ideas page [19:54:00] Hahaha [19:54:11] joed: we got it, you got my support +1, etc [19:54:22] joed trips hadrian [19:54:54] joed: cmueller will post this on the public mailing list [19:54:57] one of you will make it=85 :) [19:55:01] now I have proof, i'll sue you [19:55:26] joed trips cmueller too [19:55:29] Hahaha [19:55:42] hadrian slaps both cmueller and joed with a fish [19:55:48] ok, I will put it on the page with my ideas [19:55:49] back to work guys [19:56:08] so I think we need some flexibility on how we build the routes [19:56:19] right now there's only one way [19:56:27] true [19:56:38] cibsen (~cibsen@78-72-73-107-no33.tbcn.telia.com) joined the channel. [19:56:44] and the dsl, btw smells like the fish I slapped you with :) [19:57:00] you have a hodge podge of high level and low level things [19:57:17] and xml. [19:57:26] and one may argue that setHeader and setBody are not eips (as defined in the book) [19:57:27] but only having a separate bundle/jar doesn't solve the problem [19:57:36] for the dsl [19:57:45] so .transform(body()... or .transform(header()... [19:57:49] may be a better way, etc [19:58:03] ah, of course not, but it's a prerequisite :) [19:58:45] why? [19:59:07] because you don't need the dsl at runtime at all [19:59:15] i may want to build my route manually [19:59:19] I think we need some "extension points" [19:59:24] neat, lean runtime [19:59:29] agree [19:59:49] so runtime and dsl don't quite belong together [19:59:54] however they will look like [20:00:04] ok, understood [20:00:21] cmueller: that doesn't mean that we won't have an uber-jar having both [20:00:38] we probably will and it'd be called camel-core [20:00:47] and look pretty much like 2.x [20:01:03] that's where we can maintain the back compat as well [20:01:08] makes sense? [20:01:12] yes [20:01:13] ... and time's up [20:01:17] :) [20:01:43] We have the idea "More flexible routes at runtime= " [20:01:55] this match [20:02:17] yeah, need to work on it a bit [20:02:46] joed: thanks for volunteering :) [20:02:49] I also have to think about it [20:02:56] how it can work [20:03:04] hahaha [20:03:36] we need of course some more champions [20:03:38] cmueller: start by wiring processors manually, get the functionality you want [20:03:41] boday (~boday@64-73-244-147.static-ip.telepacific.net) joined the channel. [20:03:54] and see how that route looks compared to the dsl generated one [20:03:58] you'll be surprised :) [20:04:22] I'm sooo lazy - do you have an example for me? ;) [20:04:55] i have to dig a bit, but sure, i'll send you a sample [20:05:01] thx [20:05:23] cool, made some progress today [20:05:28] yes [20:05:51] cmueller: can you ask christian ohr if he'd volunteer for champion? [20:05:52] I have to leave in a few minutes [20:05:57] you're in the same time zone [20:06:01] yes, please [20:06:11] I will do it [20:06:11] i meant you, not me :) [20:06:14] cool [20:06:23] so let's adjourn for today [20:06:26] thx [20:06:31] next week - same time? [20:06:37] sure, should work [20:06:44] or should we talk earlier? [20:06:54] and if you ping me, i won't miss the begining [20:07:23] either way, i am on this channel a lot [20:07:28] although mostly quiet [20:07:44] chirino (~ chirino@pool-71-180-128-149.tampfl.fios.verizon.net) joined the channel. [20:08:03] tjs (~tjs@c-71-197-42-48.hsd1.fl.comcast.net) left IRC. ("Leaving...") [20:08:04] I know, but some more people and some more discussion here would be great [20:08:08] tjs (~tjs@c-71-197-42-48.hsd1.fl.comcast.net) joined the channel. [20:08:55] ok, thanks guys [20:08:55] tjs (~tjs@c-71-197-42-48.hsd1.fl.comcast.net) left IRC. (Client closed connection) [20:08:59] gotta run, take care [20:09:06] I have to leave [20:09:22] will post it later to the dev@ list [20:09:35] by by -- --e89a8fb1f6ca55f49d04d4723312--