cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
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 16:17:20 GMT
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/

Mime
View raw message