cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: ECM++
Date Wed, 20 Oct 2004 08:45:00 GMT
Carsten Ziegeler wrote:

>I already committed the first version of ECM++ into the whiteboard.
>Now, the question is how do we want to continue?
>I already integrated it into 2.2 on my computer. It requires only a few
>changes in and in some treeprocessor classes.
>Should I switch 2.2 to use ECM++ now or do we first want to write some
>(ECM++ is not buildable standalone, you have to copy the classes into
>the Cocoon src directory - but we could add the required libs if needed)
IMO you can switch 2.2 to use ECM++ right away. But maybe a vote would 
be appropriate, as it least might be percived as a large step. As long 
as ECM++ not is buildable standalone, the threshold for other people to 
write tests or working on the code might be so high that you risk to 
need to do everything yourself.

>As ECM++ doesn't support Composable and ComponentSelector anymore,
>the XSP block is currently not working - we have to switch it to Serviceable
>as well - but that isn't really a problem. I will do that as soon
>as I have time for it.
What about temporarilly re-adding the Composable and ComponentSelector 
code to ECM++. Then we get rid of the dependency between the tasks of 
adding ECM++ and the XSP refactoring. Then we can remove Composable and 
ComponentSelector as soon as the XSP refactoring is finished. Of course 
you could also break XSP for a while to motivate people to refactor XSP 
;) But in general I believe in the XP ideas of requiring the system to 
be working all of the time and really trying to avoid dependencies 
between sub projects, so that you can work on them in parallell.


View raw message