Daniel Fagerstrom wrote: > > 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. > True!
> >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. > Yes, in general you're right, but readding Composable etc. is nearly the same work then refactoring XSP which should be very simple. So I would opt for saving the extra work of readding things. Carsten
