You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2006/12/21 16:16:51 UTC
Re: svn commit: r489224 - in /cocoon/trunk/core: ./ cocoon-blocks-fw/cocoon-blocks-fw-impl/
cocoon-common/ cocoon-common/src/ cocoon-common/src/main/ cocoon-common/src/main/java/
cocoon-common/src/main/java/org/ cocoon-common/src/main/java/org/apache/
coco...
danielf wrote:
> Author: danielf
> Date: Wed Dec 20 15:35:57 2006
> New Revision: 489224
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=489224
> Log:
> Further work on splitting the core so that it becomes layered. Created a number of new modules:
>
> * cocoon-common - classes needed everywhere: Constants, ProcessingException and their dependencies.
> * cocoon-configuration - The Settings interface and implementation.
> * cocoon-environment - The Cocoon environment API and the http implementation and some abstract base classes.
> * cocoon-util - Part of the o.a.c.util package that is needed in the modules listed above.
>
Hmm, I'm not sure but it seems to me that this is the far opposite to
our old monolithic structure. What is the difference between "common"
and "util"?
We should rethink our environment abstraction as well. As we have
discussed in the past, it would make sense to forget about it and use
the servlet api instead. So I think we should not make this available in
a separate module which will be obsolete soon again. What about adding
this to the pipeline api?
Carsten
Re: svn commit: r489224 - in /cocoon/trunk/core: ./ cocoon-blocks-fw/cocoon-blocks-fw-impl/
cocoon-common/ cocoon-common/src/ cocoon-common/src/main/ cocoon-common/src/main/java/
cocoon-common/src/main/java/org/ cocoon-common/src/main/java/org/apache/
coco...
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Hi Daniel,
>
> thanks for the explanations. I'm fine with that approach and wait for
> further things to come :)
+1
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: svn commit: r489224 - in /cocoon/trunk/core: ./ cocoon-blocks-fw/cocoon-blocks-fw-impl/
cocoon-common/ cocoon-common/src/ cocoon-common/src/main/ cocoon-common/src/main/java/
cocoon-common/src/main/java/org/ cocoon-common/src/main/java/org/apache/
coco...
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi Daniel,
thanks for the explanations. I'm fine with that approach and wait for
further things to come :)
Carsten
Daniel Fagerstrom wrote:
> Carsten Ziegeler skrev:
>> danielf wrote:
>>
>>> Author: danielf
>>> Date: Wed Dec 20 15:35:57 2006
>>> New Revision: 489224
>>>
>>> URL: http://svn.apache.org/viewvc?view=rev&rev=489224
>>> Log:
>>> Further work on splitting the core so that it becomes layered. Created a number of new modules:
>>>
>>> * cocoon-common - classes needed everywhere: Constants, ProcessingException and their dependencies.
>>> * cocoon-configuration - The Settings interface and implementation.
>>> * cocoon-environment - The Cocoon environment API and the http implementation and some abstract base classes.
>>> * cocoon-util - Part of the o.a.c.util package that is needed in the modules listed above.
>>>
>>>
>> Hmm, I'm not sure but it seems to me that this is the far opposite to
>> our old monolithic structure.
> I agree that the current split is a little bit to fine grained. I
> started by just factoring out a pipeline implementation, but there are
> so many interdependencies so it didn't work that well.
>
> My current idea is to continue splitting up the core with the goal of
> making the core layered so that the pipeline can be used separately
> without needing to include all of the tree-processor code.
>
> This will lead to more modules than what we would like to have in the
> end. But it will make it clear how everything is connected. Then in a
> next step we can start refactoring things so that we get rid of
> unnecessary dependencies. And after that we probably can merge some of
> the modules. It will also be much easier for us to see and be able to
> discuss about what layers we want Cocoon to be split into.
>
> So see the current split as a temporary state, (and be prepared on that
> it will become even worse ;) )
>
>> What is the difference between "common"
>> and "util"?
>>
> Probably not that much. It might be that common, configuration and util
> should be merged.
>
>> We should rethink our environment abstraction as well. As we have
>> discussed in the past, it would make sense to forget about it and use
>> the servlet api instead.
> Agree.
>
>> So I think we should not make this available in
>> a separate module which will be obsolete soon again. What about adding
>> this to the pipeline api?
>>
> I made the environment a separate module as both pipeline and the
> container code depends on it. Otherwise it would be unclear if the
> pipeline should depend on the container or the opposite way around. If
> we can get rid of the dependency of the container on the environment, we
> could merge the environment ant the pipeline module.
>
> ==============
>
> So please bear with a too fine grained splitting of the core during a
> short period. It shouldn't affect use of Cocoon during that period as
> cocoon-core will depend on all that is needed. If we don't do enough
> progress into splitting Cocoon core in reasonable layers, it is very
> easy to merge everything together again.
>
> /Daniel
>
>
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: svn commit: r489224 - in /cocoon/trunk/core: ./ cocoon-blocks-fw/cocoon-blocks-fw-impl/
cocoon-common/ cocoon-common/src/ cocoon-common/src/main/ cocoon-common/src/main/java/
cocoon-common/src/main/java/org/ cocoon-common/src/main/java/org/apache/
coco...
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> danielf wrote:
>
>> Author: danielf
>> Date: Wed Dec 20 15:35:57 2006
>> New Revision: 489224
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=489224
>> Log:
>> Further work on splitting the core so that it becomes layered. Created a number of new modules:
>>
>> * cocoon-common - classes needed everywhere: Constants, ProcessingException and their dependencies.
>> * cocoon-configuration - The Settings interface and implementation.
>> * cocoon-environment - The Cocoon environment API and the http implementation and some abstract base classes.
>> * cocoon-util - Part of the o.a.c.util package that is needed in the modules listed above.
>>
>>
> Hmm, I'm not sure but it seems to me that this is the far opposite to
> our old monolithic structure.
I agree that the current split is a little bit to fine grained. I
started by just factoring out a pipeline implementation, but there are
so many interdependencies so it didn't work that well.
My current idea is to continue splitting up the core with the goal of
making the core layered so that the pipeline can be used separately
without needing to include all of the tree-processor code.
This will lead to more modules than what we would like to have in the
end. But it will make it clear how everything is connected. Then in a
next step we can start refactoring things so that we get rid of
unnecessary dependencies. And after that we probably can merge some of
the modules. It will also be much easier for us to see and be able to
discuss about what layers we want Cocoon to be split into.
So see the current split as a temporary state, (and be prepared on that
it will become even worse ;) )
> What is the difference between "common"
> and "util"?
>
Probably not that much. It might be that common, configuration and util
should be merged.
> We should rethink our environment abstraction as well. As we have
> discussed in the past, it would make sense to forget about it and use
> the servlet api instead.
Agree.
> So I think we should not make this available in
> a separate module which will be obsolete soon again. What about adding
> this to the pipeline api?
>
I made the environment a separate module as both pipeline and the
container code depends on it. Otherwise it would be unclear if the
pipeline should depend on the container or the opposite way around. If
we can get rid of the dependency of the container on the environment, we
could merge the environment ant the pipeline module.
==============
So please bear with a too fine grained splitting of the core during a
short period. It shouldn't affect use of Cocoon during that period as
cocoon-core will depend on all that is needed. If we don't do enough
progress into splitting Cocoon core in reasonable layers, it is very
easy to merge everything together again.
/Daniel