You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Christian Müller <ch...@gmail.com> on 2013/01/29 20:14:19 UTC
[DISCUSS CAMEL 3.0] weekly IRC chat at 01/29/2013 7:00PM - 8:00PM CET
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 (~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] <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 (~textual@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 (~textual@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 (~
textual@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 (~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] <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 (~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] <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 (~gmazza@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 (~textual@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 (~gnodet@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 (~textual@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 (~textual@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 (~
geaaru@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 (~textual@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 (~textual@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 (~cibsen@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 (~boday@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 (~
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] <cmueller> 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] <cmueller> 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] <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
--