Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <4176258C.8040908@nada.kth.se>
Date: Wed, 20 Oct 2004 10:45:00 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: ECM++
References: <200410200633.i9K6X2Of013172@mx3.nada.kth.se>
In-Reply-To: <200410200633.i9K6X2Of013172@mx3.nada.kth.se>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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