On Fri, Aug 19, 2011 at 4:54 PM, Christian Schneider
ch...@die-schneider.net wrote:
We could do something like that but the problem is the scope and dependency
rules for this new package.
Main needs access to all inner details of camel. So you only would like to
put classes in that package
Hi All,
I am currently looking into the dependencies betwen packages in
camel-core. The packages org.apache.camel and org.apache.camel.spi form
the camel api.
So I am trying to make them not depend on other packages from
camel-core. One problem there is the starter class Main.
It needs
On Fri, Aug 19, 2011 at 3:40 PM, Christian Schneider
ch...@die-schneider.net wrote:
Hi All,
I am currently looking into the dependencies betwen packages in camel-core.
The packages org.apache.camel and org.apache.camel.spi form the camel api.
So I am trying to make them not depend on other
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
Just digged deeper into ServiceSupport. It references
org.apache.camel.Service. So if we can agree that util may use the API
and the API may not use util then it could be moved there.
I am not sure if a class you extend from is a util class though. When I
think of a util class I rather think of
I am not sure moving Main to a main package is a good idea.
As you would lock yourself into only having the Main class there.
What about adding a org.apache.camel.support package.
And then have more commonly used Camel classes by end users in there.
Such as the Main class.
But by naming it
We could do something like that but the problem is the scope and
dependency rules for this new package.
Main needs access to all inner details of camel. So you only would like
to put classes in that package that also need such details. On the other
hand this package should
be accessed by
