----- Original Message ----- From: "Erik Hatcher" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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 I'll > just <taskdef> it and show it that way and provide the additional > MimeMail.java/.class (or pointers to the e-mail list archive where that code > lives). I think it would be in the best interest of Ant to let the <mail> > 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 fine > 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, complete > 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. -steve
