ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: modifying optional task code / <mimemail>
Date Thu, 07 Jun 2001 21:26:20 GMT

----- Original Message -----
From: "Erik Hatcher" <>
To: <>
Sent: Thursday, June 07, 2001 06:10
Subject: Re: modifying optional task code / <mimemail>

> > > I'm also using the <mimemail> task to e-mail the HTML reports but
> > > I'm sure since its not already an existing optional task that I can
> > > get by with <taskdef>'ing for my article.
> >
> > Some people announced that they'd be willing to work on Steve's task -
> > would we make things easier if his original task would be committed?
> > I doubt that anybody would -1 that task.
> Sure, but like you said there wouldn't be a release build prior to
> publication, so I'd still have to refer to a nightly build, but rather
> just <taskdef> it and show it that way and provide the additional
> (or pointers to the e-mail list archive where that
> lives).   I think it would be in the best interest of Ant to let the
> and <mimemail> tasks merge so there is only one official task that can
> handle attachments optionally, but for the sake of my article it'll be
> to refer to a custom task and mention that the ant-dev group is working on
> it.   I will even give it a shot to work on the merger of the two,
> with the <fileset> piece to replace the comma-delimited list of files to
> attach or include to an e-mail.   Speaking of which - how should that
> "files" attribute be treated if its replaced with the fileset feature?
> Should it be removed?   Deprecated to still work as it currently does, but
> just append <fileset> files to that list if provided?

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 task
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.

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

> Another related question - does anyone know how to use JavaMail
> to send attachments such as HTML files so that e-mail readers that support
> it can view them inline rather than require the attachment to be opened?

no idea, but the use of multipart/alternative and multipart/related content
types may be partof the puzzle.

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


View raw message