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/
