Steve Loughran <[EMAIL PROTECTED]> wrote:

> One feature of the mail task is that it needs no extra jars; the
> mimemail task has enough dependencies to make its use very optional,
> and you cant even build it without using reflection left right and
> centre.

Or you don't even try to use reflection and put the implementation of
the JavaMail implementation of the mail task into optional.jar

> A merged task would have to do this if it wanted to be fully
> backwards compatible and support build/deployments on systems
> without the extra jars.

Not really.  Make the mail task a facade task that will try to
instantiate the JavaMail implementation and fall back to the plain old
version if it cannot load that class.

> If the mimemail task moves to a fileset, we should pull the files
> attribute.

Unless we had a merged task, of course.

Stefan

Reply via email to