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 Cocoon.java and in some treeprocessor classes.
Should I switch 2.2 to use ECM++ now or do we first want to write some
tests?
(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.
/Daniel
