+1 for Camel API part, in this way we can let camel-core and
camel-spring test with single camel test framework.
But I think this change should be part of Camel 3.0, as it is not small
piece of cake :)
On 9/1/11 2:06 PM, Christian Schneider 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
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
