The problem is absolutely not about naming. The problem is that
camel-core contains about 70k lines of code.
So what we need is to have a small subset of this code that components
can depend on. The smaller the better.
Currently any change in camel-core could break any component. If we had
a proper API then only API changes could break the components.
Am 19.08.2011 15:59, schrieb Claus Ibsen:
I wonder if the impl package had been named core instead, if that
would make the tangles more tolerable?
As depending on core for me always seems okay :)
Depending on core is not ok. It means depending on implementation
details. Only very few classes should need to depend on impl or core.
Typically the code to initialize camel has to depend on it but
components and the bulk of customer code should only depend on the API.
In OSGi we can even completely hide the initialization code from users
by using services.
Anyway we have ServiceSupport in impl which IMHO should have been in
util. That would have been nice as its a good base
class to extend if your class need to be a Camel Service. I wonder if
an experiment by moving it from impl to util will reduce some tangles.
I am not sure if util is a good place. But you are right it should not
be in impl. If it is needed by components it should either be in
org.apache.camel or we need an additional package with classes that are
widely used.
Util could be used but then util may not be used by any API package as
it would create a cycle.
Christian
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
