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 23:14:10 GMT

----- Original Message -----
From: "Erik Hatcher" <>
To: <>
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
> > 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
> that they can't be included?   Couldn't they at least be used for the
> 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
> would run fine without those .jars present until someone specified that
> attribute (and the docs would state that the additional .jars are needed
> MIME mail is desired, of course).
> Or am I missing something?
> Isn't it acceptable behavior to get a ClassNotFound exception on the
> task when the 'type="mime"' is specified and the docs explicitly say to
> 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?



View raw message