I think I used runtime in the wrong context. What I meant is that you
only need the builders when you set up a route. Then while it runs you
don´t need it anymore.
A component implementation should have no knowledge about the dsl that
created it. The advantage is then that the dsl can be changed without
touching the component.
That is why I think a component should only depend on some kind of api
part of camel core.
Also when the user creates his own processor then inside this
implementation he should not know about builders. He should be able to
introspect the existing but I don´t think he needs to change it at that
time.
Best Regards
Christian
Am 19.10.2010 15:22, schrieb James Strachan:
On 19 October 2010 13:59, 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.
I don't follow this comment. When would the builders and DSL be used
other than at runtime? Every use case I've seen of the builders and
DSLs is for runtime stuff; defining routes at runtime; often using
runtime dependency injection.
--
----
http://www.liquid-reality.de
