----- Original Message ----- From: "Erik Hatcher" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 07, 2001 14:57 Subject: Re: modifying optional task code / <mimemail>
> > 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. > > 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? Its fine to have the mail task bail out in mime mode if the jars arent there, but I dont want to stop non-mime mail from even building on a machine without the extra jars. One could work around this with a mail facade task filling in a parameter object with all the arguments, then handing it off to an implementation which is either textmail or mimemail, using Class.forName to load and invoke the mimemail back end. The build.xml would not include the mimemail task if the jars were missing, but the existing task would still build and run. This is a lot of work though. While we are at it, we need to look at the java1.1 compatibility status of mimemail. Someone needs to test this stuff with javaMail 1.1.3, that still being d/l-able from sun. Any takers? -steve -steve
