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/mai
danielf wrote: Author: danielf Date: Wed Dec 20 15:35:57 2006 New Revision: 489224 URL: http://svn.apache.org/viewvc?view=revrev=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/mai
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=revrev=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
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/mai
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=revrev=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/mai
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
