Robert Burrell Donkin ha scritto:
On Wed, Feb 6, 2008 at 5:40 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
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?
all sounds doable with a little thought and effort
i think that the principle's right and we can move most of the mailets
quickly and easily. there are probably some which are more difficult
and maybe some where the effort involved is probably greater than the
gain.
unless anyone jumps in with more comments soon, i'll pull together
something that people can vote on...
-robert
+1
Stefano
