On Wed, Aug 31, 2011 at 10:15 PM, Donald Whytock <dwhyt...@gmail.com> wrote: > On Wed, Aug 31, 2011 at 3:26 PM, Claus Ibsen <claus.ib...@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 > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
