Hi Liz, Yes the code should be as simple as it can ever get. With that being said, I think these are the features that required:
* Testable * Should be able to go through the directory as well as the jar files. * It would be nice if it is fully tested (setting up files and check the search result) Does that sound right? Shane (On a side note, it sounds that you don't think Cotta was easy to read. Would you mind giving me some thoughts on that? Whateven on your mind would be appreciated. You can send it in another email. Thanks a lot) On 3/14/07, Elizabeth Keogh <[EMAIL PROTECTED]> wrote:
"Shane Duan" <[EMAIL PROTECTED]> wrote on 14/03/2007 01:24:05: > Sorry that I didn't know you had problem with it. > > Can we agree that this is needed? I can work on adding the code by > without pulling in Cotta code (I actually have created a jbehave > extension in cotta project after I updated to jbehave 1.0). > > Once I have the loader re-implemented, I can look and see why there > were duplications. I think the duplications may have been caused because it was picking up the AllBehaviours classes as well as normal behaviours? If we can avoid making too many layers of abstractions, that would also be good. I agree that if we're writing to the file system we might need an abstraction - that was the reason for the original pre-Cotta filesystem stub - but I haven't had any problems reading from it yet in any of the behaviours which do that. So, a behaviour method which looks for the targets in the classpaths using plain old java.io and / or reflection might be easier to understand and maintain than a Cotta clone! Does that make any sense? Please feel free to disagree with me! Cheers, Liz. -- Elizabeth Keogh [EMAIL PROTECTED] http://www.livejournal.com/users/sirenian
-- Shane http://www.shaneduan.com --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
