camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <>
Subject Re: What is the purpose of camel-core-xml? Move the code to camel-core?
Date Thu, 01 Sep 2011 08:04:41 GMT
+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
>> <> 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 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
>>>>>>> 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
>>>>>> easier to keep them in sync and whatnot.
>>>>> --
>>>>> --
>>>>> Christian Schneider
>>>>> Open Source Architect
>>>>> Talend Application Integration Division
>>> --
>>> Christian Schneider
>>> Open Source Architect

Blog: (English)
Twitter: willemjiang
Weibo: willemjiang

View raw message