On Fri, Aug 19, 2011 at 4:54 PM, Christian Schneider
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 that also need such det
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 nothing
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 suppor
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
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 p
On Fri, Aug 19, 2011 at 3:40 PM, Christian Schneider
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 packages from camel-c
