Robert Burrell Donkin ha scritto:
On Feb 6, 2008 8:40 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Robert Burrell Donkin ha scritto:
On Feb 5, 2008 7:32 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
2) Will the mailet util library be an "util" product similar to api, std
and crypto?
not sure we need a util library ATM. if possible, i'd prefer to
include the utils in std for now.
The only issue is that some "library" module in james-server will have
to depend on std-mailets because of these utilities (unless we duplicate
the utility code).
But we can split them later, if needed.
providing that it's the coupled classes are mailets that haven't been
moved from JAMES then i'm happy for a temporary dependency
- robert
Some example that does not satisfy the requirement:
mailets/ClamAVScan
- import org.apache.james.util.io.IOUtil;
Maybe this could be translated to a commons-io dependency
mailets/SpamAssassin
- import org.apache.james.util.SpamAssassinInvoker;
What to do with this? An smtphandler in in smtpserver in james may
require the same code. That's why it has been astracted to an utility class.
mailets/AbstractRedirect and the associated tree
- import org.apache.james.util.mail.dsn.DSNStatus
Maybe this should land mailet-api sooner or later.
- import org.apache.james.util.mail.MimeMultipartReport
Not sure what code uses this.
- import org.apache.james.util.MimeMessageUtil(for writeMessageBodyTo)
Maybe this function is simple enough we can duplicate it.
WDYT?
Stefano
