ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject Re: modifying optional task code / <mimemail>
Date Thu, 07 Jun 2001 21:57:29 GMT
> 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. A merged
> would have to do this if it wanted to be fully backwards compatible and
> support build/deployments on systems without the extra jars.
> so, i'm -1 on a merged task, +1 on fileset into mimemail.

I'm not sure I fully understand/agree with the merged task and its
dependencies being that much of a problem.   The official builds at
Jakarta's site could include those jars (mail.jar and activation.jar) just
like it includes junit.jar, couldn't it?  Or is there a licensing issue such
that they can't be included?   Couldn't they at least be used for the builds
but perhaps not packaged?   (The <script> task is like this, correct?
bsf.jar isn't distributed, is it?  But must be used for builds, no?)

And if the merged task had an attribute 'type' such that type="mime" (or
something like this) is what got it to use the MimeMail kinda stuff then it
would run fine without those .jars present until someone specified that
attribute (and the docs would state that the additional .jars are needed if
MIME mail is desired, of course).

Or am I missing something?

Isn't it acceptable behavior to get a ClassNotFound exception on the <mail>
task when the 'type="mime"' is specified and the docs explicitly say to use
that feature you need those additional .jars?

> If the mimemail task moves to a fileset, we should pull the files
> There's no need to deprecate an attribute of a task which wasn't even in
> of the nightly builds. Which is an argument on not committing it till that
> is done.

Agreed.  I'll make the modification to MimeMail for the fileset feature and
remove the files attribute.

I'm perfectly fine with there being two different mail tasks, one built-in,
one optional.   I just want to see the MimeMail functionality committed in
some form or another.

> > Another related question - does anyone know how to use JavaMail
> > to send attachments such as HTML files so that e-mail readers that
> > it can view them inline rather than require the attachment to be opened?
> no idea, but the use of multipart/alternative and multipart/related
> types may be partof the puzzle.

I'll experiment with this, and add any additional appropriate attributes to
the MimeMail task to allow this to be specified (defaulting of course to its
current behavior).

> Anyway, you are welcome to use the task in your paper. Send us all a
> to the paper when it is done, and submit the changed tasks too.

I will definitely send a pointer - but usually someone else sees my articles
posted before I do, so I might be slow to the draw on when it appears!  :)
And you can count on all changes I make being submitted back to ant-dev.


View raw message