Something of an outsider here, but I personally would like to see camel-core broken into smaller pieces for the sake of my OSGi-based app. At the moment the camel-core .jar is larger than my entire app, including the felix .jar. I really like the idea of using camel, but it makes me wince to more than double the size of my deployable binary. Surely there's something in camel-core that doesn't absolutely have to be there for simple runtime use?
Don On Tue, Oct 19, 2010 at 9:31 AM, Richard Kettelerij <[email protected]> wrote: > Concerning the 2.0 vs. 3.0 debate. I agree with James and Claus that it > would be better to change the major version when you require Spring 3.0 and > Java 6. > > To illustrate, I'm still stuck at Java 5 (we'll probably move to Java 6 in > 2011 Q1), so upgrading to Camel 3.0 isn't possible. Nevertheless when Camel > 3.0 is in development I would still love to see blocking issues being fixed > on the 2.x branch. Changing the major version makes this possible (like you > guys did with the 1.x branch). > > On Tue, Oct 19, 2010 at 2:59 PM, Schneider Christian < > [email protected]> wrote: > >> Hi James, >> >> it is not absolutely necessary to split the jar into three jars. More >> important is to have rules that say that a component developer should only >> depdend on the API part and to check that the internal dependencies do not >> have cycles between the three logical modules. The only disadvantage of not >> breaking up camel core into three modules is that maven will not help you in >> avoiding cycles which would be the case with separate modules. As the rules >> can be checked with tools like structure 101 this is not too bad though. >> >> I don´t think the cyclic depdencies are only a "metric". They are a real >> problem when the code grows as you can not understand or change anything >> isolated. To have three clearly defined parts in camel core that should not >> have cycles between them is quite reasonable imho. >> >> Especially I think the builders should be separated as they are not needed >> at runtime. The builder pattern creates many cycles and it confuses people >> who try to understand the runtime behaviour. Of course I do not speak >> against builders and the dsl. They are extremely convenient and clear to use >> for end users and make a good part of the appeal of camel. >> >> So to sum it up I think breaking up camel-core logically is very important. >> At the same time I understand that ease of use is a value that is probably >> as important as a clear architecture. The good thing is that I am quite sure >> that we can achieve both. >> >> Best Regards >> >> Christian >> >> >> Christian Schneider >> Informationsverarbeitung >> Business Solutions >> Handel und Dispatching >> >> Tel : +49-(0)721-63-15482 >> >> EnBW Systeme Infrastruktur Support GmbH >> Sitz der Gesellschaft: Karlsruhe >> Handelsregister: Amtsgericht Mannheim HRB 108550 >> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck >> Geschäftsführer: Jochen Adenau, Hans-Günther Meier >> >> >> -----Ursprüngliche Nachricht----- >> Von: James Strachan [mailto:[email protected]] >> Gesendet: Dienstag, 19. Oktober 2010 14:31 >> An: [email protected] >> Betreff: Re: Some thoughts about the architecture of camel >> >> >> > >> > So my idea would be to split camel-core into three parts: >> > >> > api, builder, impl >> >> What benefits do you see for end users and component developers having >> to depend on at least 3 jars rather than one? >> >> One of the reasons I like camel-core as it is; its nice and simple and >> just works. You can build & run routes with some simple components >> using the single camel-core jar. (Just add camel-test to do testing). >> >> Sure there's some cyclic package dependencies. Given the large number >> of use cases in Camel (route design, testing, JAXB model, Java DSL and >> base set of components) its kinda hard to totally avoid those while >> having convention over configuration, decent defaults etc. >> >> I value ease of use for end users & component developers and backwards >> compatibility over cyclic dependency metrics any day :) >> >> -- >> James >> ------- >> http://macstrac.blogspot.com/ >> >> Open Source Integration >> http://fusesource.com/ >> >
