You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Christian Schneider <ch...@die-schneider.net> on 2011/08/19 15:40:25 UTC
[HEADS UP] Moving org.apache.camel.Main to org.apache.camel.main.Main
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 access to impl packages as it needs to start camel. So it
should not live in org.apache.camel.
I propose to move it to org.apache.camel.main. To not break anything
right now I will create a deprecated class Main in org.apache.camel. We
can remove the deprecated version in camel 3.0
See https://issues.apache.org/jira/browse/CAMEL-4357
Christian
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [HEADS UP] Moving org.apache.camel.Main to org.apache.camel.main.Main
Posted by Christian Schneider <ch...@die-schneider.net>.
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 a small class I instantiate and
call or even call simply static methods.
Perhaps we would need a special package for such base classes. Not sure
how to name it though.
Christian
Am 19.08.2011 16:31, schrieb Christian Schneider:
>
>> 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
Re: [HEADS UP] Moving org.apache.camel.Main to org.apache.camel.main.Main
Posted by Claus Ibsen <cl...@gmail.com>.
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 that also need such details. On the other hand
> this package should
> be accessed by nothing else as it would easily create tangles over most of
> camel.
>
I guess main is a corner case and moving it to .main could make sense
in that case.
> For example the ServiceSupport class should not go in the same package as
> Main as ServiceSupport will be needed by many other classes.
>
> Christian
>
>
> Am 19.08.2011 16:43, schrieb Claus Ibsen:
>>
>> 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 support we give us legroom to put in other useful
>> classes.
>>
>>
>>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [HEADS UP] Moving org.apache.camel.Main to org.apache.camel.main.Main
Posted by Christian Schneider <ch...@die-schneider.net>.
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 else as it would easily create tangles over most
of camel.
For example the ServiceSupport class should not go in the same package
as Main as ServiceSupport will be needed by many other classes.
Christian
Am 19.08.2011 16:43, schrieb Claus Ibsen:
> 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 support we give us legroom to put in other useful classes.
>
>
>
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [HEADS UP] Moving org.apache.camel.Main to org.apache.camel.main.Main
Posted by Claus Ibsen <cl...@gmail.com>.
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 support we give us legroom to put in other useful classes.
On Fri, Aug 19, 2011 at 4:31 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
> 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
>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [HEADS UP] Moving org.apache.camel.Main to org.apache.camel.main.Main
Posted by Christian Schneider <ch...@die-schneider.net>.
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
Re: [HEADS UP] Moving org.apache.camel.Main to org.apache.camel.main.Main
Posted by Claus Ibsen <cl...@gmail.com>.
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 packages from camel-core.
> One problem there is the starter class Main.
>
> It needs access to impl packages as it needs to start camel. So it should
> not live in org.apache.camel.
>
> I propose to move it to org.apache.camel.main. To not break anything right
> now I will create a deprecated class Main in org.apache.camel. We can remove
> the deprecated version in camel 3.0
>
> See https://issues.apache.org/jira/browse/CAMEL-4357
>
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 :)
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.
> Christian
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/