You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Erik Hatcher <er...@earthlink.net> on 2001/06/07 05:17:30 UTC
modifying optional task code /
I am in the process of modifying one of Ant's optional tasks (<junit> and
<junitreport> specifically). I, incorrectly I'm guessing, compiled the two
classes I modified (JUnitTest.java and XMLJUnitResultFormatter.java) and
modified my classpath to have their directory ahead of optional.jar in hopes
they'd get picked up from there. Ant actually pulled them from
optional.jar instead. I haven't dug deep enough into Ant's internals to
really understand how this is happening, but could someone explain to me
(point me to the code if possible) how/why this happens?
Also, is there a way I can keep the standard release build of ant.jar and
optional.jar in the lib directory and still override some of optional.jar's
classes?
I'm writing an article (for IBM's developerWorks) on Ant/JUnit integration
and how to automate running unit tests and having the testing report (thanks
to Stephane's cool <junitreport> tag). Since my code modifications
probably won't be committed before I submit the article, I want to explain
how to get my enhancements working prior to their integration into an
official Ant build. The way I've done it is to simply run bootstrap.bat
and replace my previous ant.jar and optional.jar files with the newly built
ones. It would be nicer if I could do something easier than having folks
build ant.jar and optional.jar themselves if at all possible.
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. Steve Loughran - any objections to me
providing your task with my article? (I will definitely give the disclaimer
that it will probably be modified but e-mailing attachments will most likely
be available as an Ant task in the near future with the same or similar
syntax - but until then that this piece could be used with <taskdef>).
Thanks for all your help.
Erik
Re: modifying optional task code /
Posted by Stefan Bodewig <bo...@apache.org>.
Steve Loughran <st...@iseran.com> wrote:
> 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.
Or you don't even try to use reflection and put the implementation of
the JavaMail implementation of the mail task into optional.jar
> 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.
Not really. Make the mail task a facade task that will try to
instantiate the JavaMail implementation and fall back to the plain old
version if it cannot load that class.
> If the mimemail task moves to a fileset, we should pull the files
> attribute.
Unless we had a merged task, of course.
Stefan
Re: modifying optional task code /
Posted by Stefan Bodewig <bo...@apache.org>.
Erik Hatcher <er...@earthlink.net> wrote:
> 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?
It could, but this could very soon start a religuos war 8-) - just
think of the maintenance issue, the junit.jar in Ant's CVS is 3.2
while 3.7 is the current version. But lets not open yet another flame
war, that's not worth it.
I don't think official builds include junit.jar, we have been
including JAXP, but this is a mandatory dependency for Ant.
> Or is there a licensing issue such that they can't be included?
Possible, I haven't checked the license on JavaMail, but if it is the
same as the one on JAXP, it would be OK.
> 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?)
<script> is an optional task!
BSF is installed on a number of developer machines, including the one
that does the nightly builds.
> 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?
Well, wrap it into a BuildException and add some explanation 8-)
> I will definitely send a pointer - but usually someone else sees my
> articles posted before I do, so I might be slow to the draw on when
> it appears! :)
Do we have all relevant pointers on
<http://jakarta.apache.org/ant/resources.html>?
Stefan
My SendMailTask as-is (WAS: modifying optional task code / )
Posted by Paulo Gaspar <pa...@krankikom.de>.
Sorry about the slow reaction but I am now busy with something completely
different.
I just took a look at Steve's MimeMail task and it is quite similar to mine.
PROs and CONs I can guess at a first look:
- Steve's MimeMail is possibly more similar to the standard mail task, to
which I did not pay enough attention (although I took a look at it);
- My "SendMailTask" extends MatchingTask and, that way, can use the usual
fileset functionality from Ant.
This is a slight modification of a test task I made (and yes, it worked):
<taskdef name="mymail" classname="SendMailTask"/>
<mymail from="my.myself.I@myhost.org"
tolist="someone@somewhere.com,someone.else@somewhereelse.org"
subject="This mail was sent from java..."
smtphost="mail.myhost.org"
dir="${export.dir}"
includes="Export.zip,export.dtd">
...and there should be a couple of files
attached to it.
</mymail>
I am still interested in merging the best of these 2 tasks, but the problem
is priority related. When I made my previous posting this was the top one
thing to do. But since then, this one got postponed and I got other
troubles.
Keep in mind that this is just something I hacked in an afternoon just after
discovering that Ant is good for exports too (it runs other code from the
command line, selects files, zips them, deletes them) but missed the file
sending bit.
This means that:
- It seems to work well;
- But I knew almost nothing about Ant before that day (only messed with
making a build.xml for myself for the 1st time that morning);
- And it is my first mail sending code (a nice tutorial from Sun helped
a lot).
Steve's mail code looks a lot like mine.. and since it works, maybe that
part is OK. However, I still have some doubts on the fileset usage, that I
just copied from another task. I am not sure if excluding files in the
fileset definition and less trivial stuff like that will work correctly.
Anyway, I got a lot for free and the least I can do is to give back what I
have. I hope this can help someone and I am sorry and don't have the time
right know to improve it a bit. I still hope to get back at it.
I will make time for any questions, but I will be offline until Sunday.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Erik Hatcher [mailto:erikhatcher@earthlink.net]
> Sent: Thursday, June 07, 2001 5:18 AM
> To: ant-dev
> Subject: modifying optional task code / <mimemail>
>
>
> I am in the process of modifying one of Ant's optional tasks (<junit> and
> <junitreport> specifically). I, incorrectly I'm guessing,
> compiled the two
> classes I modified (JUnitTest.java and XMLJUnitResultFormatter.java) and
> modified my classpath to have their directory ahead of
> optional.jar in hopes
> they'd get picked up from there. Ant actually pulled them from
> optional.jar instead. I haven't dug deep enough into Ant's internals to
> really understand how this is happening, but could someone explain to me
> (point me to the code if possible) how/why this happens?
>
> Also, is there a way I can keep the standard release build of ant.jar and
> optional.jar in the lib directory and still override some of
> optional.jar's
> classes?
>
> I'm writing an article (for IBM's developerWorks) on Ant/JUnit integration
> and how to automate running unit tests and having the testing
> report (thanks
> to Stephane's cool <junitreport> tag). Since my code modifications
> probably won't be committed before I submit the article, I want to explain
> how to get my enhancements working prior to their integration into an
> official Ant build. The way I've done it is to simply run bootstrap.bat
> and replace my previous ant.jar and optional.jar files with the
> newly built
> ones. It would be nicer if I could do something easier than having folks
> build ant.jar and optional.jar themselves if at all possible.
>
> 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. Steve Loughran - any objections to me
> providing your task with my article? (I will definitely give the
> disclaimer
> that it will probably be modified but e-mailing attachments will
> most likely
> be available as an Ant task in the near future with the same or similar
> syntax - but until then that this piece could be used with <taskdef>).
>
> Thanks for all your help.
>
> Erik
>
>
Re: modifying optional task code /
Posted by Stefan Bodewig <bo...@apache.org>.
Steve Loughran <st...@iseran.com> wrote:
> 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?
JavaMail 1.1.3 is on its way onto my disk. You can be sure that I'll
test it before I/as soon as somebody else commit/s it.
Stefan
Re: modifying optional task code /
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Erik Hatcher" <er...@earthlink.net>
To: <an...@jakarta.apache.org>
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
Re: modifying optional task code /
Posted by Erik Hatcher <er...@earthlink.net>.
> 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?
> 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.
Agreed. I'll make the modification to MimeMail for the fileset feature and
remove the files attribute.
I'm perfectly fine with there being two different mail tasks, one built-in,
one optional. I just want to see the MimeMail functionality committed in
some form or another.
> > 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.
I'll experiment with this, and add any additional appropriate attributes to
the MimeMail task to allow this to be specified (defaulting of course to its
current behavior).
> 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.
I will definitely send a pointer - but usually someone else sees my articles
posted before I do, so I might be slow to the draw on when it appears! :)
And you can count on all changes I make being submitted back to ant-dev.
Thanks,
Erik
Re: modifying optional task code /
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Erik Hatcher" <er...@earthlink.net>
To: <an...@jakarta.apache.org>
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
Re: modifying optional task code /
Posted by Erik Hatcher <er...@earthlink.net>.
Paulo,
Thanks for correcting my oversight of your CC and BCC, as well as the fix
for the missing basedir.
Yup, the HTML e-mail is a nice feature, especially for JUnit results!
Erik
----- Original Message -----
From: "Paulo Gaspar" <pa...@krankikom.de>
To: <an...@jakarta.apache.org>
Cc: <er...@earthlink.net>
Sent: Monday, June 11, 2001 5:49 AM
Subject: RE: modifying optional task code / <mimemail>
> Hi Erik,
>
>
> I agree that my coding style is different and that Steve's task is the
> way to go - even (besides code style) because he was more careful about
> compatibility with the existing mail task.
>
> However, there was an interesting bit you missed in my task: having CC
> (Carbon Copy) and BCC (Blind Carbon Copy) recipient lists. For some
> tasks these can be (as my data exports (o;= ) they can be quite
> important.
>
> There was also had a bug on building filenames for filesets - a base
> directory argument was missing for building the File objects.
>
> BUT I just loved the HTML mail thing! It really works!
> =:oD
>
>
> I made some fixes for the above problems and I send attached to this
> mail both my new version of the MimeMail task ("MimeMail.java") and a
> diff ("patch.txt") of the changes I made.
>
>
> Going trough the changes as shown in the diff file:
> 1- Changed imports to make dependencies explicit on a class-by-class
> basis;
> 2- Added "ccList" and "bccList" properties;
> 3- Changed validate() method to reflect the addition of the "ccList"
> and "bccList" properties - now the rule for destination is that
> at least one of "toList", "ccList" and "bccList" properties
> should be filled;
> 4- Added addRecipients() helper method which helps on adding the
> addresses for each of the recipient lists. Another change is that
> I use the InternetAddress.parse() method instead of a
> StringTokenizer to build parse those lists;
> 5- Fixed the above mentioned bug by using the base directory for
> each file in a file set;
> 6- Changed the message of the exception thrown when a file does not
> exist or is not readable (this helped me diagnosing the above
> mentioned bug) in order to also show the absolute path of such
> file.
>
>
> Now I am throwing away my task and using this one.
> =:o)
>
> Have fun,
> Paulo Gaspar
>
>
>
> > -----Original Message-----
> > From: Erik Hatcher [mailto:erikhatcher@earthlink.net]
> > Sent: Monday, June 11, 2001 7:19 AM
> > To: ant-dev
> > Subject: Re: modifying optional task code / <mimemail>
> >
> >
> > Stefan, Steve, Paulo, and others interested,
> >
> > Attached is a .zip file with my modifications for the JUnitReport task
and
> > the MimeMail task. Shall I post the patch difference files also so
that
> > someone can commit these changes if they are acceptable?
> >
> > Note - There has been a change since the 1.3 release to
> > XMLJUnitResultFormatter, but my code is built on the 1.3 codebase.
> >
> > The MimeMail task that is attached is a modified version of Steve's
task.
> > I've also included an HTML file in Ant-style describing its
> > usage. I added
> > the FileSet capability, and another attribute called 'messageFile' so
that
> > the message body can be pulled either from the 'message' attribute or
from
> > the file pointed to by 'messageFile'. The handy thing about
> > 'messageFile'
> > is that HTML files can be sent so that e-mail readers will recognize
them
> > inline rather than as an attachment (but the messageMimeType must be
> > specified as "text/html" also). This is nice when sending
> > JUnitReport HTML
> > results.
> >
> > I will address a few issues that have been brought up:
> >
> > - Should we merge MimeMail and Mail? It would be nice, but is
> > unnecessary.
> > Its probably not a huge effort, but more effort than its worth
> > since whoever
> > needs the MimeMail capability can just get the necessary .jar files and
> > <taskdef>.
> >
> > - Should the other JUnitResultFormatters be modified to pick up the
newly
> > added properties with the JUnitTask modification? I looked at the
> > PlainJUnitResultFormatter, and did not want to mess with its output as
> > someone may be relying on it as-is, but its easy enough for any of these
> > formatters to be modified to grab these properties if desired.
> > startTestSuite(JUnitTest suite) and endTestSuite(JUnitTest
> > suite) both, of
> > course, have access to the JUnitTest and I added a method on JUnitTest
> > called getProperties that hands back a Properties object that contains
the
> > name/value pairs. Stefan proposed a different method to hand
Properties
> > off to the formatters - I'm not sure what his proposed method
> > gives us that
> > mine misses.
> >
> > - As for Paulo's task - now that MimeMail has been modified to support
> > FileSet's there really isn't much difference except MimeMail has the
> > messageMimeType. MimeMail seems to be more in line with the coding
style
> > of the other Ant tasks. I vote we stick with MimeMail and make that an
> > optional task.
> >
> > - I've included the necessary XSL files to generate an overview of JUnit
> > tests. I only modified overview-summary.xsl (but toolkit.xsl is
> > needed in
> > the same directory). I added the display of each test-suites
> > properties -
> > and in IE5 the display of these properties can be toggled. I
> > didn't spend
> > a lot of time making this display of the properties really nice, but the
> > good thing is now that they are there in the XML its easy enough to do
> > something with them. Let me know if you have any suggestions on how
they
> > should be reported.
> >
> > - This probably isn't behavior that can be relied upon, but by placing
> > JUnitMail.jar into my ANT_HOME/lib directory I'm able to
> > <taskdef> MimeMail
> > and it works fine, as well as have my modified JUnitTask picked up in
the
> > classpath prior to the one in optional.jar. I'm assuming this is
because
> > the loop in Ant.bat to add the lib .jar files is picking them up
> > alphabetically. Will this work consistently on Windows and
> > other platforms
> > in this manner if folks are using the wrapper scripts to start Ant?
> >
> > Thanks again for everyones assistance,
> > Erik
> >
> >
>
RE: modifying optional task code /
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi Erik,
I agree that my coding style is different and that Steve's task is the
way to go - even (besides code style) because he was more careful about
compatibility with the existing mail task.
However, there was an interesting bit you missed in my task: having CC
(Carbon Copy) and BCC (Blind Carbon Copy) recipient lists. For some
tasks these can be (as my data exports (o;= ) they can be quite
important.
There was also had a bug on building filenames for filesets - a base
directory argument was missing for building the File objects.
BUT I just loved the HTML mail thing! It really works!
=:oD
I made some fixes for the above problems and I send attached to this
mail both my new version of the MimeMail task ("MimeMail.java") and a
diff ("patch.txt") of the changes I made.
Going trough the changes as shown in the diff file:
1- Changed imports to make dependencies explicit on a class-by-class
basis;
2- Added "ccList" and "bccList" properties;
3- Changed validate() method to reflect the addition of the "ccList"
and "bccList" properties - now the rule for destination is that
at least one of "toList", "ccList" and "bccList" properties
should be filled;
4- Added addRecipients() helper method which helps on adding the
addresses for each of the recipient lists. Another change is that
I use the InternetAddress.parse() method instead of a
StringTokenizer to build parse those lists;
5- Fixed the above mentioned bug by using the base directory for
each file in a file set;
6- Changed the message of the exception thrown when a file does not
exist or is not readable (this helped me diagnosing the above
mentioned bug) in order to also show the absolute path of such
file.
Now I am throwing away my task and using this one.
=:o)
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Erik Hatcher [mailto:erikhatcher@earthlink.net]
> Sent: Monday, June 11, 2001 7:19 AM
> To: ant-dev
> Subject: Re: modifying optional task code / <mimemail>
>
>
> Stefan, Steve, Paulo, and others interested,
>
> Attached is a .zip file with my modifications for the JUnitReport task and
> the MimeMail task. Shall I post the patch difference files also so that
> someone can commit these changes if they are acceptable?
>
> Note - There has been a change since the 1.3 release to
> XMLJUnitResultFormatter, but my code is built on the 1.3 codebase.
>
> The MimeMail task that is attached is a modified version of Steve's task.
> I've also included an HTML file in Ant-style describing its
> usage. I added
> the FileSet capability, and another attribute called 'messageFile' so that
> the message body can be pulled either from the 'message' attribute or from
> the file pointed to by 'messageFile'. The handy thing about
> 'messageFile'
> is that HTML files can be sent so that e-mail readers will recognize them
> inline rather than as an attachment (but the messageMimeType must be
> specified as "text/html" also). This is nice when sending
> JUnitReport HTML
> results.
>
> I will address a few issues that have been brought up:
>
> - Should we merge MimeMail and Mail? It would be nice, but is
> unnecessary.
> Its probably not a huge effort, but more effort than its worth
> since whoever
> needs the MimeMail capability can just get the necessary .jar files and
> <taskdef>.
>
> - Should the other JUnitResultFormatters be modified to pick up the newly
> added properties with the JUnitTask modification? I looked at the
> PlainJUnitResultFormatter, and did not want to mess with its output as
> someone may be relying on it as-is, but its easy enough for any of these
> formatters to be modified to grab these properties if desired.
> startTestSuite(JUnitTest suite) and endTestSuite(JUnitTest
> suite) both, of
> course, have access to the JUnitTest and I added a method on JUnitTest
> called getProperties that hands back a Properties object that contains the
> name/value pairs. Stefan proposed a different method to hand Properties
> off to the formatters - I'm not sure what his proposed method
> gives us that
> mine misses.
>
> - As for Paulo's task - now that MimeMail has been modified to support
> FileSet's there really isn't much difference except MimeMail has the
> messageMimeType. MimeMail seems to be more in line with the coding style
> of the other Ant tasks. I vote we stick with MimeMail and make that an
> optional task.
>
> - I've included the necessary XSL files to generate an overview of JUnit
> tests. I only modified overview-summary.xsl (but toolkit.xsl is
> needed in
> the same directory). I added the display of each test-suites
> properties -
> and in IE5 the display of these properties can be toggled. I
> didn't spend
> a lot of time making this display of the properties really nice, but the
> good thing is now that they are there in the XML its easy enough to do
> something with them. Let me know if you have any suggestions on how they
> should be reported.
>
> - This probably isn't behavior that can be relied upon, but by placing
> JUnitMail.jar into my ANT_HOME/lib directory I'm able to
> <taskdef> MimeMail
> and it works fine, as well as have my modified JUnitTask picked up in the
> classpath prior to the one in optional.jar. I'm assuming this is because
> the loop in Ant.bat to add the lib .jar files is picking them up
> alphabetically. Will this work consistently on Windows and
> other platforms
> in this manner if folks are using the wrapper scripts to start Ant?
>
> Thanks again for everyones assistance,
> Erik
>
>
Re: modifying optional task code /
Posted by Erik Hatcher <er...@earthlink.net>.
Stefan, Steve, Paulo, and others interested,
Attached is a .zip file with my modifications for the JUnitReport task and
the MimeMail task. Shall I post the patch difference files also so that
someone can commit these changes if they are acceptable?
Note - There has been a change since the 1.3 release to
XMLJUnitResultFormatter, but my code is built on the 1.3 codebase.
The MimeMail task that is attached is a modified version of Steve's task.
I've also included an HTML file in Ant-style describing its usage. I added
the FileSet capability, and another attribute called 'messageFile' so that
the message body can be pulled either from the 'message' attribute or from
the file pointed to by 'messageFile'. The handy thing about 'messageFile'
is that HTML files can be sent so that e-mail readers will recognize them
inline rather than as an attachment (but the messageMimeType must be
specified as "text/html" also). This is nice when sending JUnitReport HTML
results.
I will address a few issues that have been brought up:
- Should we merge MimeMail and Mail? It would be nice, but is unnecessary.
Its probably not a huge effort, but more effort than its worth since whoever
needs the MimeMail capability can just get the necessary .jar files and
<taskdef>.
- Should the other JUnitResultFormatters be modified to pick up the newly
added properties with the JUnitTask modification? I looked at the
PlainJUnitResultFormatter, and did not want to mess with its output as
someone may be relying on it as-is, but its easy enough for any of these
formatters to be modified to grab these properties if desired.
startTestSuite(JUnitTest suite) and endTestSuite(JUnitTest suite) both, of
course, have access to the JUnitTest and I added a method on JUnitTest
called getProperties that hands back a Properties object that contains the
name/value pairs. Stefan proposed a different method to hand Properties
off to the formatters - I'm not sure what his proposed method gives us that
mine misses.
- As for Paulo's task - now that MimeMail has been modified to support
FileSet's there really isn't much difference except MimeMail has the
messageMimeType. MimeMail seems to be more in line with the coding style
of the other Ant tasks. I vote we stick with MimeMail and make that an
optional task.
- I've included the necessary XSL files to generate an overview of JUnit
tests. I only modified overview-summary.xsl (but toolkit.xsl is needed in
the same directory). I added the display of each test-suites properties -
and in IE5 the display of these properties can be toggled. I didn't spend
a lot of time making this display of the properties really nice, but the
good thing is now that they are there in the XML its easy enough to do
something with them. Let me know if you have any suggestions on how they
should be reported.
- This probably isn't behavior that can be relied upon, but by placing
JUnitMail.jar into my ANT_HOME/lib directory I'm able to <taskdef> MimeMail
and it works fine, as well as have my modified JUnitTask picked up in the
classpath prior to the one in optional.jar. I'm assuming this is because
the loop in Ant.bat to add the lib .jar files is picking them up
alphabetically. Will this work consistently on Windows and other platforms
in this manner if folks are using the wrapper scripts to start Ant?
Thanks again for everyones assistance,
Erik
Re: modifying optional task code /
Posted by Stefan Bodewig <bo...@apache.org>.
Erik Hatcher <er...@earthlink.net> wrote:
>> 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.
No chance of an Ant release, not even a beta 8-)
> 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").
Well, it would probably better to advise people to extract the
complete ....optional.junit package from that nightly build and
replace the one in their Ant 1.3 copy with that package.
We've fixed some bugs from Ant 1.3 but sure opened new ones in areas
completely unrelated to the junit tasks.
I'm not sure whether the junitreport task is part of the nightly
builds at all, BTW.
> 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,
Probably.
> 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.
Yes, I like the fileset idea. Creating the merger may be tricky, but
not impossible.
> 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?
Should be deprecated. But I'd probably convert the files list to a
patternset and create a fileset with dir="." from it.
Stefan
Re: modifying optional task code /
Posted by Erik Hatcher <er...@earthlink.net>.
> 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
> CLASSPATH.
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
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? (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.
Erik
Re: modifying optional task code /
Posted by Stefan Bodewig <bo...@apache.org>.
Erik Hatcher <er...@earthlink.net> wrote:
> I, incorrectly I'm guessing, compiled the two classes I modified
> (JUnitTest.java and XMLJUnitResultFormatter.java) and modified my
> classpath to have their directory ahead of optional.jar in hopes
> they'd get picked up from there.
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
CLASSPATH.
> Also, is there a way I can keep the standard release build of
> ant.jar and optional.jar in the lib directory and still override
> some of optional.jar's classes?
If the wrapper script is the culprit - you'll have to modify the
wrapper itself.
> Since my code modifications probably won't be committed before I
> submit the article, I want to explain how to get my enhancements
> working prior to their integration into an official Ant build.
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.
> 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.
Stefan