Am 31.08.2011 21:34, schrieb Claus Ibsen:
On Wed, Aug 31, 2011 at 3:28 PM, Christian Schneider
<[email protected]> wrote:
Frankly by introducing WrappedFile in the root package, which is,
according to you, a temporary solution, is a bad idea. You now add
more confusion to the mix. Just because a structure 101 diagram should
have one less arrow less. Instead you end up pushing more and more to
the root package, and make it more and more general. Abstract over
abstraction :(
It is not about a line in an architecture tool. It is about making the
file component independent of the rest of camel. The disadvantage of
having the file component in camel-core is that people do not really
have an eye on dependencies.
In my point of view there should be two architectural rules for components:
1) A component should only know about the camel-api
2) The camel-core as well as camel-api should not know about the
component at all
So the fact the GwericFile was used in camel-core outside of the file
component means that rule 2 is not followed. Btw. if the component is a
separate project this can not happen so easily. So what I did with
WrappedFile is create an interface that makes the file component more
compliant to rule 2 again. The WrappedFile abstraction can be removed
again as soon as the file component simply transports File objects or
other well known objects. Transporting private classes of the component
is the real bad thing.
There are two violations of rule 1 that are not yet solved for the file
component. CorePackageScanClassResolver and ToStringTypeConverter from
impl.converter still use GenericFile and GenericFileConverter. I will
try to resolve this too.
Btw. I just digged a bit deeper into the dependencies of the file
component to see how far away from following rule 1 we are right now.
Currently the file component still uses 10 impl classes and
converter.IOConverter as well as processor.MemoryIdempotentRepository.
These will also require quite a lot of work.
So again this should not be any insult against anyone in our fine
community. We do not yet have the above rules about components. So no
one can be blamed for not following them. I just try to clean things up
and on the way I try to figure out what could be good rules for the
future. At a later time I will propose the rules on the dev list so we
can make them official if they make sense. It all comes down to bring
camel into a state that allows further growth and allows to react on new
requirements in the same fast pace that we had in the past. If we do not
clean up and create those rules camel will soon be very difficult to
change and will not be able to grow as well as it did in the past.
So to re-iterate my thoughts. Keep the 2.x as is. Consider changes for
Camel 3.0 if it makes sense and is feasible.
Absolutely. Removing the generics is only an option for the 3.x release.
Christian
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
