Not sure about the need for a separate repository though. Personally, I would rather see this as part of the source in the current repository. This enables the tests to be maintained and distributed in sync. with the source. Ultimately, I would like to add these, and many other, unit test runs to the build process. Doing so would validate that a build is logically correct as well as compilationally correct.
I mean the whole Sieve codebase (that is independent of the server) be a separate CVS repository. I agree we should keep the tests with the source code.
I'm purposely not assuming any kind of deployment scenario at this time. This should be usable with any kind of James container or Mailet refactoring that gets done.
That said, integration will probably be at the processor level with a 'processor' Sieve Action Command invoking a James processor - which may be a Mailet processor.
I'll need to go through sieve again since you're implementing this (i.e., it may become a reality). I like the idea of sieve as a processor, but could see the per-user processing be within a single mailet.
-- Serge Knystautas President Lokitech >>> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
