Component Overview

(Official) Project Status

The current status (updated 11/2006) is available through SVN [http://svn.apache.org/repos/asf/jakarta/commons/proper/email/trunk/STATUS.html here].

Recently resolved issues (last updated Aug 20 2007)

New features

(Added in rev 545815) [https://issues.apache.org/jira/browse/EMAIL-35 EMAIL-35]: Allow [DataSources] to be directly embedded in [HtmlEmails].

Bug fixes

email 1.0 doesn't handle HTML embedding or attachments correctly. This is really bad, and is reason enough for a 1.1 release.

(Added in rev 510708) [https://issues.apache.org/jira/browse/EMAIL-50 EMAIL-50]: HTML mail doesn't display correctly (the issue says in Outlook 2000, but the display fails on every common mail client I tried). It's not an Outlook-specific error. A patch is available that fixes this and has been tested on several different clients; also, the new patch adheres properly to the MIME specs in RFC 2045-2049 where email 1.0 did not. The fix also resolves two other open issues:

• [https://issues.apache.org/jira/browse/EMAIL-28 EMAIL-28]: HTML attachments don't work correctly.

• [https://issues.apache.org/jira/browse/EMAIL-52 EMAIL-52]: Don't embed the same URL multiple times in the same email.
  

Character set fixes/support

email 1.0 provided limited support for different charsets, and it's generated four issues.

(Added in rev 510275) [https://issues.apache.org/jira/browse/EMAIL-1 EMAIL-1]: Default email charset not used for text content. A patch has been uploaded that defines three different cases for this behavior and tests/fixes each.

(Added in rev 510715) [https://issues.apache.org/jira/browse/EMAIL-54 EMAIL-54]: Propose a new Charset enum. The current patch uses the JDK 1.4 java.nio.charset.Charset class to validate user-supplied charset names. This removes the need for a separate enumeration of "supported" classes and greatly reduces the headache of maintaining the support as the JVM continues to evolve. This also incorporates fixes for two other open issues:

• [https://issues.apache.org/jira/browse/EMAIL-25 EMAIL-25]: Can't set charset for a single address.

• [https://issues.apache.org/jira/browse/EMAIL-14 EMAIL-14]: Support a couple specific charsets.
  

Build fixes/enhancements

(Added in rev 510706) [https://issues.apache.org/jira/browse/EMAIL-62 EMAIL-62]: Enforce 1.4 source/bytecode in ant and maven 1 builds

(Added in rev 510704) [https://issues.apache.org/jira/browse/EMAIL-63 EMAIL-63]: Submitted maven 2 pom.xml.

(Added in rev 544629) [https://issues.apache.org/jira/browse/EMAIL-64 EMAIL-64]: use a different test email server from a live project, not a dead one. Patch available to use wiser from the [http://subethasmtp.tigris.org/ subethasmtp project]. The test cases have been ported and the wiser packages uploaded to maven2 for the enjoyment of all.

Waived features

(Waived for 1.1) [https://issues.apache.org/jira/browse/EMAIL-56 EMAIL-56]: Support creating Email subclasses from [MimeMessages].

(BenSpeakmon) One of the MimeMessage constructors in JavaMail (both 1.3 and 1.4) already does this, BTW. I'm not sure this is something that falls within commons-email's scope. The commons-email API, I think, is for the common cases where you just want to build and send an email without needing the power (or complexity) of JavaMail. If you're already pulling messages from an email server, I don't know why you wouldn't just use JavaMail for manipulating it – the power and complexity is just what you need for those kinds of jobs. And it doesn't seem worth the trouble to duplicate any of that code in commons-email when the existing code works just fine. I'd recommend WONTFIXing this one.

[https://issues.apache.org/jira/browse/EMAIL-6 EMAIL-6]: Allow attaching one subclass of Email to another.

_(BenSpeakmon) I'm not convinced that it's useful to support attaching one subclass of Email to another subclass – that is, the original report creates an HtmlEmail and then wants to attach that to a MultiPartEmail. The current design of commons-email would make this very tricky, but aside from that I don't see the general usefulness of doing so. One case where I do see a use for this would be when the user wants to attach a MimeMessage he got from somewhere (like a server or a filestore) to a subclass of Email. This would mean adding MultiPartEmail.addMimeMessage() methods which would then be attached like the current addPart() methods. (We'd have to have different names, since MimeMessage doesn't share a common interface ancestor with MimeMultipart.) There's still a problem, though; such a MimeMessage would have arbitrarily complex content in it. It could be multipart, HTML text, full of attachments, etc., and there's no way to know what really needs to be attached.

I think that this has to fall into that class of problems that would be better served with JavaMail, so I'd recommend this be wontfixed._

Open issues (last updated Aug 20 2007)

These are the currently open issues organized according to category.

New feature requests

[https://issues.apache.org/jira/browse/EMAIL-65 EMAIL-65]: Improve [HtmlEmail] MIME layout.

Morten Hatteson makes the point that the MIME structure generated by HtmlEmail after the patch for EMAIL-50 could be better in spec compliance. I doubt we can fix it properly while still maintaing backward compatibility, but we should see if it can be improved to some degree. This is likely going to be the last release of this component, and I'd like to leave it in as good a shape as possible if I'm going to tell users to live with it forever.

Release Plan

In addition to performing steps in http://jakarta.apache.org/commons/releases/prepare.html, also do the following:

• Get maven 2 build to the point where it can do everything the m1 build does
• Remove the m1 build
• Do a javadoc pass; leave no public/protected member undocumented
• Run complete build, test, and package cycle on JDK 1.4, 5, and 6
• Upload my gpg key for signing the release