cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject 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...
Date Thu, 21 Dec 2006 15:58:11 GMT
Carsten Ziegeler skrev:
> danielf wrote:
>> Author: danielf
>> Date: Wed Dec 20 15:35:57 2006
>> New Revision: 489224
>> URL:
>> 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
>> * 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
> 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.

>  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.


View raw message