Quantcast

[DISCUSS CAMEL 3.0] weekly IRC chat at 02/19/2013 7:00PM - 8:00PM CET

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[DISCUSS CAMEL 3.0] weekly IRC chat at 02/19/2013 7:00PM - 8:00PM CET

Christian Mueller
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
[19:01:20] <cmueller>     and our road map here:
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 (~
[hidden email]) 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 (~[hidden email]) 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 (~[hidden email]) left
IRC. (gnodet)
[19:17:13]      iocanel (~[hidden email]) 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 (~
[hidden email]) 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 (~
[hidden email]) 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 (~[hidden email])
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 (~[hidden email]) 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
[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 (~[hidden email]) 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 (~[hidden email])
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/
[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 (~[hidden email]) 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 (~[hidden email]) 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 (~[hidden email])
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

--
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/19/2013 7:00PM - 8:00PM CET

Christian Mueller
Christian, Claus, others...
could you please have a look at the following commit:
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 <
[hidden email]> 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
> [19:01:20] <cmueller>     and our road map here:
> 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 (~
> [hidden email]) 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 (~[hidden email]) 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 (~[hidden email])
> left IRC. (gnodet)
> [19:17:13]      iocanel (~[hidden email]) 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 (~
> [hidden email]) 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 (~
> [hidden email]) 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 (~[hidden email])
> 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 (~[hidden email]) 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
> [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 (~[hidden email]) 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 (~[hidden email])
> 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/
> [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 (~[hidden email])
> 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 (~[hidden email]) 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 (~[hidden email])
> 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
>
> --
>
>


--
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/19/2013 7:00PM - 8:00PM CET

Christian Schneider
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/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 <
> [hidden email]> 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
>> [19:01:20] <cmueller>     and our road map here:
>> 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 (~
>> [hidden email]) 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 (~[hidden email]) 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 (~[hidden email])
>> left IRC. (gnodet)
>> [19:17:13]      iocanel (~[hidden email]) 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 (~
>> [hidden email]) 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 (~
>> [hidden email]) 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 (~[hidden email])
>> 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 (~[hidden email]) 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
>> [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 (~[hidden email]) 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 (~[hidden email])
>> 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/
>> [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 (~[hidden email])
>> 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 (~[hidden email]) 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 (~[hidden email])
>> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/19/2013 7:00PM - 8:00PM CET

Guillaume Nodet
Administrator
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 <
[hidden email]> 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 <
>> [hidden email]> 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<[hidden email]>)
>>> 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 (~[hidden email].**net<[hidden email]>)
>>> 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<[hidden email]>
>>> )
>>> left IRC. (gnodet)
>>> [19:17:13]      iocanel (~[hidden email].**otenet.gr<[hidden email]>)
>>> 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<[hidden email]>)
>>> 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<[hidden email]>)
>>> 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 <[hidden email]>)
>>> 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 (~[hidden email]) 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 (~[hidden email].**net<[hidden email]>)
>>> 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<[hidden email]>
>>> )
>>> 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<[hidden email]>
>>> )
>>> 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 (~[hidden email].**otenet.gr<[hidden email]>)
>>> 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 <[hidden email]>)
>>> 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: [hidden email]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/19/2013 7:00PM - 8:00PM CET

Christian Schneider
Hi Guillaume,

I am not absolutely mandating a rewrite. The new API will simply allow
us to do any change in core we want. That can be a rewrite but it does
not have to be.
I know that the aproach with a new API is more work than a simple
refacturing.  The big advantage is that we can stay compatible with the
old core using the bridging.
So we will have some time to convert the modules and also refine the
api. Hadrian brought up the great idea that we can in fact create the
new API and the bridge before we have to
really start a camel 3 branch.

My proposal does not even touch the DSL though. The API should in a
first step only be the foundation for component developers.
A next step is the Model and the DSL. I have not done enough experiments
with this to have an opinion how a new model and DSL should look like.
It is unlikely though that any bigger change there can stay compatible.

I think DSL and model should be separated. Basically we even now have a
separation between dsl and "model". The dsl elements already create the
processors to run the routes. The main change I would like to see here
is that runtime model does not use processors but a richer abstraction
of the model. What I would like to achieve is that the runtime model the
dsl creates does not contains any cross cutting concerns like
transaction, security, ....
A nicer DSL would be great but we could even delay that till camel 4.

I can not prove though that this aproach is necessary. I would be really
glad if someone manages to refactor camel to a clean API without this
big step. So the first thing we have to do is decide if a new (kind of
independent API)
is really necessary. The best way to achieve this is to try to refactor
core in a branch or a private checkout and see how far you get. I would
like to encourage everyone to try that and report their experiences. So
if a refactoring is possible I am glad to abandon the idea with the new API.

Christian

Am 27.02.2013 10:32, schrieb Guillaume Nodet:

> 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 <
> [hidden email]> wrote:
>

--
 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [DISCUSS CAMEL 3.0] weekly IRC chat at 02/19/2013 7:00PM - 8:00PM CET

Guillaume Nodet
Administrator
Refactoring or new api.  Is that really the goal in itself ?
What new features are needed that can't be done with the current code ?

Anyway, there's no real point in discussing that really.  if you want to
experiment with a new api, just do it in a branch and we'll discuss that
once there is something to see.
You don't have to ask for permission to do it, though you need to inform
the community about it. Which is done now.
That's exactly what I told Hadrian at ApacheCon.  Do it in  branch or
sandbox.  Then, discuss it.

On Wed, Feb 27, 2013 at 12:43 PM, Christian Schneider <
[hidden email]> wrote:

> Hi Guillaume,
>
> I am not absolutely mandating a rewrite. The new API will simply allow us
> to do any change in core we want. That can be a rewrite but it does not
> have to be.
> I know that the aproach with a new API is more work than a simple
> refacturing.  The big advantage is that we can stay compatible with the old
> core using the bridging.
> So we will have some time to convert the modules and also refine the api.
> Hadrian brought up the great idea that we can in fact create the new API
> and the bridge before we have to
> really start a camel 3 branch.
>
> My proposal does not even touch the DSL though. The API should in a first
> step only be the foundation for component developers.
> A next step is the Model and the DSL. I have not done enough experiments
> with this to have an opinion how a new model and DSL should look like. It
> is unlikely though that any bigger change there can stay compatible.
>
> I think DSL and model should be separated. Basically we even now have a
> separation between dsl and "model". The dsl elements already create the
> processors to run the routes. The main change I would like to see here is
> that runtime model does not use processors but a richer abstraction of the
> model. What I would like to achieve is that the runtime model the dsl
> creates does not contains any cross cutting concerns like transaction,
> security, ....
> A nicer DSL would be great but we could even delay that till camel 4.
>
> I can not prove though that this aproach is necessary. I would be really
> glad if someone manages to refactor camel to a clean API without this big
> step. So the first thing we have to do is decide if a new (kind of
> independent API)
> is really necessary. The best way to achieve this is to try to refactor
> core in a branch or a private checkout and see how far you get. I would
> like to encourage everyone to try that and report their experiences. So if
> a refactoring is possible I am glad to abandon the idea with the new API.
>
> Christian
>
> Am 27.02.2013 10:32, schrieb Guillaume Nodet:
>
>  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 <
>> [hidden email]> wrote:
>>
>>
> --
>  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: [hidden email]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Loading...