Hello again,
sorry for the start of my mail. It looks a bit confused and I should
have started with an explanation what I try to do ;-)
First I am a big fan of camel. The java DSL is really a charm to work
with and shows that java can be used for a decent DSL what I doubted
before. In my work I need integration processes at many places and camel
is a great tool for this. So when we started to use camel more intensive
I tried to learn a bit more about camel. When I tried to understand the
big picture of the architecture I found no clues on the website. So I
started with an architecture tool and eclipse and tried to understand
what each package means and how the packages depend on each other. When
I visualized the architecture I found that there are many cycles what
made it difficult to know where to start. So after some time digging in
the code and the visualization I thought there were some places where
refactorings like moving a class would help make things much clearer. So
I started to post some small pataches as jira issues.
When looking into the architecture of other frameworks almost all have
many cycles in the package structure with one exception: The Spring
Framework. I think the clear layering is one of the key success
criterias of Spring. While at the start of a framework cycles are not
that important, they slow down further development when the framework
grows in size. At the same time when your number of developers grows you
need some basic blueprint of how the architecture should look like, so
everyone has a clue where to put new classes and what depencies to
avoid. Juergen Hoeller held a very interesting talk about the
architecture of Spring and how they manage the architecture over time.
Here is an excerpt of it:
http://mikenereson.blogspot.com/2007/06/spring-on-code-organization-for-large.html
So I had the idea to help document the architecture of camel and help to
fix some issues where possible.
That much about my motivation.
Below are some guesses I have about the architecture:
- camel and model are the base packages. Most other packages need them.
camel has only two references to model so I guess model should be above
camel.
- converter is a uitilty package that is referenced by most other
packages but does not reference other packages (except camel for the
interface Converter). So it is almost at the bottom.
- spi contains extension points for camel. It references camel and model
quite heavily so it probably is above those two.
- impl is intended for the implementation details so it probably is on
top of at least camel, model and spi.
Am I about right with these guesses?
Best regards
Christian
--
Christian Schneider
---
http://www.liquid-reality.de
