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 13:10:49 GMT
> How do you do that?  Just putting it into CLASSPATH won't help as the
> wrapper scripts put the stuff from ANT_HOME/lib in front of the

Doh!   That is indeed the culprit - sorry for that dumb mistake.   I was
setting the classpath in my environment before invoking Ant "knowing" that I
was going through the wrapper script, but not really thinking it through.
Again, I apologize for that oversight.   I haven't actually tried it, but I
just looked at ant.bat and lcp.bat and surely thats the culprit.

> What's the deadline for this?  Even if your patches get committed in
> time, it is quite possible that there will be no Ant release before
> that.

June 15 is when the article is due.   If it was committed it would be in a
nightly build that I could refer to (of course with the disclaimer "use at
your own risk").   But now that I've "seen the light" with the wrapper
script, I can just show a simple patch of that wrapper script that puts the
classpath of the newly compiled classes (and really those are only needed if
someone wants to see the full set of Ant properties that JUnit runs with).

> > 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 (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?  (probably the latter,
huh?  :)   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?

Thanks for your help.


View raw message