Re: What is the purpose of camel-core-xml? Move the code to camel-core?

[Hadrian Zbarcea <hz...@gmail.com>]

In all fairness, it's becoming more and more bloated, alright. Donald 
was right to point it out too and did it in a very nice way. He was not 
comparing apples and oranges.

My $0.02,
Hadrian


On 08/31/2011 05:14 PM, Claus Ibsen wrote:
> On Wed, Aug 31, 2011 at 10:15 PM, Donald Whytock<dw...@gmail.com>  wrote:
>> On Wed, Aug 31, 2011 at 3:26 PM, Claus Ibsen<cl...@gmail.com>  wrote:
>>> 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.
>>
>> In all fairness, 1.6 mb is bigger than the entire Felix framework,
>> including the documentation.  The camel-core jar represents two-thirds
>> of the volume of my deployed Felix OSGI application.
>>
>
> In all fairness you are comparing apples to oranges. Is it not a goal
> for the Felix project
> to be a micro container and very small, and being embeddable into
> small devices and whatnot.
>
> Thats not necessarily the same goal for Camel.
>
>
> Instead you ought to compare Camel with equal projects such as
> - Spring Integration
> - Apache Synapse
> - Mule
> - and possible others
>
> Spring Integration is about 500kb. But then you must use Spring
> Framework also. So thats about 2-3mb extra, depending on your choice
> of their JARs.
>
> Apache Synpase has a ton of JARs. I am actually not aware which one is
> the bare you need to run. The dist is 40+mb.
> Mule is about the same story as Synapse. However Mule is designed to
> be an ESB and thus bigger. But the Mule people
> also like to compare against Camel and say they can embed and run Mule
> standalone, or in WARs etc. Mule and OSGi,
> well we all may know what Ross said about that.
>
> Yes the camel-core could be splitted up but it may just add more
> confusion and trouble to the mix. We got a lot of new and less
> experienced users to Apache Camel, as they need help with integration.
> So for them being able to pick camel-core and be able to run out of
> the box is great. They dont need to fiddle with adding 8-15 JARs as
> you would do when using Spring or other which have fine grained JARs
> for the project.
>
> The 1.6 - 1.7mb in camel-core is roughly taking up space as follows
> - default implementation = 500kb
> - model = 400kb
> - eips = 400kb
> - components = 300kb
> - jmx = 100kb
> - other stuff = the rest
>
> In the components there is 3 which take up some size
> - bean, file and mock
> The rest of the components is minimal, some one one class, and others
> maybe 10-20kb
>
> The bean component is a core piece of camel and ought to be in camel-core.
> Mock is used heavily for unit testing camel itself. But also for end
> users as well.
>
> It could be moved to camel-mock, but then we would need to build
> camel-mock before camel-core to be able to test camel-core.
> Would that not cause trouble, as camel-mock depends on camel-core?
>
> Then file is not, and could be in a camel-file JAR. But then again
> when people get started
> with Camel they often try out with files. So having  that work out of
> the box is nice.
>
> And for management, Christian have prepared the API for that. And it
> would be possible to split that out in camel-core-management
> or what a component name could be for the future. If it makes sense.
>
>
> So the big pieces to split Camel would be the eips and the model. But
> those are key concepts for Camel.
> The routing and EIPs.
>
>
>
>
>> Yes, the core does a lot, but how many people genuinely use all the
>> features and built-in components?  Not that I'm necessarily advocating
>> splitting it into all separate modules, since it would probably take
>> up more space that way, what with the extra manifests and activators
>> and all.
>>
>> But still, even if not "bloated", I might call it "non-trivially sized".
>>
>> Don
>>
>
>
>