Hi Claus,
it is great that you wear the community hat. This is a needed balance to
my refactorings that are of course rather architecture focused.
The good thing is that thanks to your comments many changes are now more
compatible than I originally did them.
So of course the big question is which changes will really hit people
and make their migration more difficult. Currently we can not really
predict that.
So my proposal as I also stated in the release not is that we show
people the changes and then ask for feedback if there are changes that
really give them problems.
In that case we can rollback these changes in a fix release or introduce
more compatibility classes that help people.
Instead of a "bugfix release" we could also introduce a release
candidate for the 2.9 release and ask for feedback even before the
2.9.0. So I am quite sure we can make peoples experience quite smooth
even with the changes.
I still think that it is good to have these changes already in 2.9.0.
There are two reasons for that. First we get much quicker feedback if
changes are good. The 3.0 will take quite long and most users will only
look at it when it is finished. Second we make our own life easier when
we have to backport fixes from 3.0 to 2.9.x as 2.9 is much more similar
to 3.0 than 2.8. The problem with holding back changes for a major
release makes the change very big. This means it takes even longer to
create the major release and as it is only tested after it is released
it is very difficult to really get it right. As you said design is very
difficult and I also often change my opinion how things work best. So it
is very important to have early feedback.
So my goal was to already ship the smaller changes in 2.9 and keep the
bigger stuff for 3.0. Of course as you said we will even want 3.0 to be
as compatible as possible while making the necessary changes to be ready
for the future.
In any case the good thing is that I think I did not have to do big
changes to the examples during my refactorings. So I guess it is quite
possible that most end users will not see any big changes when they upgrade.
Christian
Am 02.09.2011 08:52, schrieb Claus Ibsen:
Hi
At first I will say that when I replied to this it was late in the
evening, so I may not have been able to
pickup the correct words, when I wrote the mail. The tone was due
"strong concerns" what has
happened over the last period to the API in camel-core.
The following I write with the viewpoint from the biggest asset we
have, the point of view from the community.
So I put on a "end user community hat".
The people in the community look at Apache Camel as a great project to
help make integration easier and quicker.
They see the project as established and "old" as Johan put it. Camel
2.x is 2+ years old, and we are to do the 10th
minor release (2.9).
What people in the community say, and what I hear is that they, after
the first couple of Camel 2.x releases.
The API stabilized and they would be able to have fairly easy upgrades
and being able to reuse existing components,
and whatnot.
As an end user you want to be able to reply on Apache Camel "staying
as is". For end users its pain and time consuming
and cost a lot of $$$ and resources if they would need to recompile
and adjust components and other adjustments due
API changes in the core. We all know that rigors testing is often
required for any changes like that to be accepted in a production
environment. So its far better if the can keep using already existing
without any recompilations.
That is why we keep the API in camel-core stable. Yes there are
classes in the core which could have a better name.
Or be moved to another package etc. But we *keep them there*. The
community want this. In all fairness they actually
dont give a damn if TimeoutMap is in util package, what matters for
them is that TimeoutMap is kept in that package in 2.x.
Designing an API is much harder than you would think. One day you
think and feel the API should be like X, then 2 days
later you think that it should be like Y etc. Just look at the
@ManagedXXX annotations.
And what should a new package be named. What about this class, should
it be named X instead of Y etc, because it
have grown since its initial start etc?
Designing APIs is much better for a new major release where you have
the luxury of time and being able to cut
milestone releases, and have feedback from early adaptors and keen end
users who want to try out and help.
Also its more accepted in the early releases (3.0, 3.1 and possible
3.2) to be a bit more open to API changes that
it would in later releases. Especially now when we have Camel 2.x
which is 2+ years. And for Camel 2.x is
really taking up and being a very popular project. So we have grown
and have a very large user base.
And people use Camel in all kind of environments and systems, that we
only have heard a tip of the iceberg.
Besides regular end users, there is many open source projects and
commercial vendors who use Camel
as part of the offerings. They use pieces of the API which normal end
users dont use as often.
In fact this is also a very important perspective of the success of
this project and community.
That commercial vendors is integrating their products with Apache
Camel. For example there
are vendors who build management and monitoring apps, cloud
infrastructure, commercial ESBs,
IDE tooling, and whatnot. Popular open source projects such as
Activiti, Akka, JBoss Drools, Smooks and
others also rely on Camel is stable. So end users can use their
products without them having pain
to upgrade and recompile their products.
Another concern of mine is that API changes was done after 2+ years
and without any prior discussion
and consensus from the Camel team. Likewise there has been absolutely
no indicators from
the community that they would like API changes in the core at this
point in time. Again I have said
many times Camel 2.x is 2+ years old, and the API needs to be stable.
What would have been a better approach would be to start a thread
about Camel 3.0, and one of the
first goals would be API changes and looking at how to split the
camel-core into smaller pieces,
if that is feasible and makes sense. Then a branch in svn could have
been setup. And for example
Christian could experiment there and gets "fingers dirty" and thus be
able to help sketch up a
solid draft in the wiki for the Camel 3.0 API. Then when time is
right, I guess that would then be soon,
we could start on Camel 3.0 officially and get the API in place with a
couple of milestone releases.
When the 3.0 API is more set in stone, then we could look at the "gap"
to 2.x, and then if possible.
start adding @deprecated in there, in case it would be possible to
"help the 2.x users" towards the 3.0 API
without any backwards breaking.
That said, it would IMHO, be a goal of the 3.0 API to be as compatible
with 2.x which would make sense.
We have a very large user based on 2.x, and it would be a shame to
loose them because 3.0 is "too different".
Another concern is that I dont think *we* (I say we, as are of us from
the Camel team) did this professionally.
For example would never see such changes from professional products
such as Spring Framework.
Which has become a key infrastructure in many organizations. It would
be great for Apache
and the Camel community, that Camel 2.x (could become / already is)
key in their integration needs.
Okay I really didnt mean to write a long email, as we all have alot to
do in our daily work and lives.
One last point. I am not trying to be the devils advocate. But from a
community point of view.
They would possible like that all the API changes would be rolled
back. No API changes in an "old"
product is what they wish for.
However what is done is done. I will lobby for that we do not repart
this in the future.
Okay I take of the "community hat". I guess there were a few parts
which had the "Camel team hat".
Okay good weekend.
And no hard feelings. We are all working in the interrest of the community.
On Thu, Sep 1, 2011 at 8:06 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
Hi Claus,
I did not intend to be disrespectful. It is natural that things become
bloated when a project grows. In fact it is very difficult to avoid.
So I think camel-core is too complex. That does not mean it is too big in
size. Even more important is that the parts of the core are not separated.
They are highly entangled.
For example the file component. You would expect that the file component
knows about the api but the rest of core does not know about the file
component. In reality the GenericFile
class was used in several places outside the file component. So the core had
knowledge about file component internals. In the case of the file component
it was wasy to change that.
The other components are similar. The bean component is the worst example.
The connections between bean component classes and core are many and
complicated and I am not yet sure how to
solve that one.
So these are just two example there are many more. The problem with
camel-core is not the size. The problem is that it is not nicely separated
logically. If the parts of the core had minimal dependencies among each
other then camel-core would be much easier to use and change and also to
test. So the minimal thing we need is a real architecture people know and
agree with - with rules that make sure that things keep manageable.
Splitting the core would be the easiest way to make the rules visible but it
is not the only way to go.
Your example of the mock component shows the problem nicely. It uses the
core but is also used to test the core. This is in fact a problem. As soon
as we have a camel-api the mock component can only depend on the api.
Then the core can depend on api and on mock for testing. That will then make
it nicely spearated.
We can then still create a big jar in the build for beginners to give them
an easy start but logically the parts of camel-core need to be nicely
separated.
Christian
Am 31.08.2011 21:26, schrieb Claus Ibsen:
On Wed, Aug 31, 2011 at 7:45 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
The camel-core is already bloated anyway. I see no reason to not include
those classes.
I may have posted the "bloated" word before which would be overstating
what I meant. What I was to say
is that camel-core-xml does not belong in camel-core, as it adds
dependency and features which the camel-core does not need.
Only the XML DSL capable components need those pieces and thus they
are in their own module. Those modules is not testable unless
you use camel-spring or camel-blueprint, and hence you would end up
with code in the camel-core which cannot be tested.
But frankly I think you are out of line and being disrespectful to the
project, the community, and the people who have
worked hard on this project. I would never call the camel-core bloated
in any negative way as you do.
The core is 1.6mb which is not bloated. In fact with the core you can
do really a lot with Camel, which impress
a lot of people, and help make the project a success it is today.
The camel-core has grown 200kb in 2.9 due that Google Code Map we
embed directly now, for improving
concurrency issues with the endpoint registry.
The current mechanism of directly including the classes in camel-spring
and
camel-blueprint is really strange and I think having some classes in core
that are not needed in some cases is much better then what we have now.
It is not strange. It was discussed and designed in the past. We
worked together with OSGi experts such as gnodet.
And Johan on the blueprint pieces etc.
We have two such modules:
camel-core-xml
camel-core-osgi
is core module for XML DSL and for running Camel in OSGi frameworks.
It just happens to be that both camel-spring and camel-blueprint uses
both of these two as
- camel-spring has a XML DSL and supports both plain Spring as well as
Spring-DM
- camel-blueprint has a XML DSL and support OSGi blueprint.
And thus we have shared and common code for those 2 components in the
camel-core-XXX components.
We will need to split the core anyway for 3.0 so reintegrating
camel-core-xml would reduce the number of jars again which is good.
That is still to be decided. And to be discussed later when Camel 3.0
is starting to take form.
Christian
Am 31.08.2011 17:54, schrieb Claus Ibsen:
On Wed, Aug 31, 2011 at 5:51 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
That sounds to me like it would fit nicely in camel-core.
No as that is just bloat to the core.
Btw. is there a reason why camel-core-xml is scope provided in
camel-spring?
This gives me errors in some tests of other components in eclipse as
these
classes can not be found.
There is no problem at all in IDEA.
Yes one of the reasons is osgi. By having the camel-core-xml .class
files included directly into the camel-spring and camel-blueprint
wo dont have any osgi hickups due JAR files not being loaded and
whatnot. That was a pain in the past.
Christian
Am 31.08.2011 17:43, schrieb Claus Ibsen:
On Wed, Aug 31, 2011 at 5:40 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
Hi all,
can someone tell me what the purpose of camel-core-xml is and why it
has
to
be a spearate project?
It does not seem to have any other dependencies than camel-core.
So if there is no good reason to keep it separate I propose to move
that
code into camel-core.
No.
Its an abstract component which has base classes used by XML DSLs such
as camel-spring and camel-blueprint.
This ensures that code is reused between the 2 XML DSLs and make it
easier to keep them in sync and whatnot.
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
