There seems to be a possible bug in ant 1.7.0 (this does NOT affect 1.6.5 or 1.6.2). When using the <mail> task in ant to generate and send an e-mail on our systems, the mail will fail to be sent with no error, no warning and no failures unless the "encoding" attribute is set to an acceptable encoding method. At my work, "mime" e-mail is unusable. However, when using an ant <mail> task as follows: <mail mailhost="stlpsmtprelay" subject="[PING-ALL] @{server.name} No longer responding to Pings!" tolist="@{notification.list}" from="ping_test@rgare.com" message="${trace.output}"/> 1.7.0 produces the following output: [mail] Failed to initialise MIME mail: javax/mail/MessagingException Run through 1.6.5 or 1.6.2 the following is the output: [mail] Failed to initialise MIME mail: javax/mail/MessagingException [mail] Using UU mail [mail] Sending email: [ANT-SERVER] cybere_mtb01 stopped...please don't use <EOM> [mail] From Deployment_Process@rgare.com [mail] ReplyTo [] [mail] To [<valid e-mail addresses here>] [mail] Cc [] [mail] Bcc [] [mail] Sent email with 0 attachments When I add an "encoding" statement onto the <mail> task above as follows: <mail mailhost="stlpsmtprelay" subject="[PING-ALL] @{server.name} No longer responding to Pings!" tolist="@{notification.list}" from="ping_test@rgare.com" message="${trace.output}" encoding="plain"/> I get the appropriate information and the e-mail generates and sends. I assume there is an issue with the "auto" code in which it makes what it thinks is an intelligent selection as to which mail type to use (in our case "MIME") but if that fails doesn't continue beyond to the next mail type like 1.6.5 and 1.6.2 does.
EmailTask is executed by using org.apache.tools.ant.taskdefs.email.Mailer that has encoding "auto" as default. If encoding is not specified, org.apache.tools.ant.taskdefs.email.MimeMailer is set to the Mailer (when encoding is not "plain"). Because MimeMailer imports javax.mail package that is not bundled with ant-1.7, linkage error occurs like below. [mail] Class org.apache.tools.ant.taskdefs.email.MimeMailer could not be loaded because of an invalid dependency. [mail] at org.apache.tools.ant.util.ClasspathUtils.newInstance(ClasspathUtils.java:296) [mail] at org.apache.tools.ant.taskdefs.email.EmailTask.execute(EmailTask.java:418) [mail] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) [mail] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [mail] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [mail] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [mail] at java.lang.reflect.Method.invoke(Method.java:585) [mail] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105) [mail] at org.apache.tools.ant.Task.perform(Task.java:348) [mail] at org.apache.tools.ant.Target.execute(Target.java:361) [mail] at org.apache.tools.ant.Target.performTasks(Target.java:389) [mail] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) [mail] at org.apache.tools.ant.Project.executeTarget(Project.java:1304) [mail] at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) [mail] at org.apache.tools.ant.Project.executeTargets(Project.java:1186) [mail] at org.apache.tools.ant.Main.runBuild(Main.java:698) [mail] at org.apache.tools.ant.Main.startAnt(Main.java:199) [mail] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) [mail] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) [mail] Caused by: java.lang.NoClassDefFoundError: javax/mail/MessagingException [mail] at java.lang.Class.forName0(Native Method) [mail] at java.lang.Class.forName(Class.java:242) [mail] at org.apache.tools.ant.util.ClasspathUtils.newInstance(ClasspathUtils.java:266) [mail] ... 18 more I think if you use email task without specify encoding, you must include mail.jar in the library classpath. activation.jar is required also. See http://ant.apache.org/manual/index.html "Library Dependencies"
introduced with svn revision 278346 where a "return" slipped into the catch block(s). fixed with svn revision 704486.