camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: What is the purpose of camel-core-xml? Move the code to camel-core?
Date Thu, 01 Sep 2011 06:06:00 GMT
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.


Am 31.08.2011 21:26, schrieb Claus Ibsen:
> On Wed, Aug 31, 2011 at 7:45 PM, Christian Schneider
> <>  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
>>> <>    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
>>>>> <>      wrote:
>>>>>> Hi all,
>>>>>> can someone tell me what the purpose of camel-core-xml is and why
>>>>>> 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
>>>> Open Source Architect
>>>> Talend Application Integration Division
>> --
>> Christian Schneider
>> Open Source Architect

Christian Schneider

Open Source Architect

View raw message