camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Müller <>
Subject [DISCUSS CAMEL 3.0] weekly IRC chat at 01/29/2013 7:00PM - 8:00PM CET
Date Tue, 29 Jan 2013 19:14:19 GMT
This was the today's discussion on IRC (irc:// 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 we should move to 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 ( left
IRC. (gnodet)
[19:00:54]      DRaCuLa ( joined the
[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
[19:05:30]      iocanel ( 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"
[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
[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 ( 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 (~ left IRC.
("Textual IRC Client:")
[19:19:10] <cmueller>     we may need some syntactic sugar in a say new
[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
[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 (
joined the channel.
[19:25:01]      olamy ( left IRC. (olamy)
[19:26:52]      boday (
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 ( left IRC.
("May the Force be with you")
[19:31:42]      iocanel ( 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
[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 (
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
[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 ( 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 (
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
[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 ( 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
[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
[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
[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 ( 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 (~ left IRC.
[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 ( left IRC.
(Ping timeout: 20 seconds)
[19:51:51] <hadrian>     cmueller: should the dsl be in a separate jar?
[19:51:55]      iocanel ( 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
[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 ( 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
[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
[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 (
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
[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 (~ joined the channel.
[20:08:03]      tjs ( left IRC.
[20:08:04] <cmueller>     I know, but some more people and some more
discussion here would be great
[20:08:08]      tjs ( joined the
[20:08:55] <cmueller>     ok, thanks guys
[20:08:55]      tjs ( 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


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message