You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Component Overview

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="9534e074-1157-42b6-9b53-05fb193e1cf8"><ac:plain-text-body><![CDATA[

http://jakarta.apache.org/commons/email/images/email-logo-white.png

[http://jakarta.apache.org/commons/email/ Commons-Email] aims to provide a API for sending email. It is built on top of the [JavaMail] API, which it aims to simplify.[BR] A lot of information is available on the [http://jakarta.apache.org/commons/email/ Commons-Email website].[BR] If you don't find the information you need you can always contact us using one of the [http://jakarta.apache.org/site/mail2.html#Commons mailing lists].

]]></ac:plain-text-body></ac:structured-macro>

(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].

Open issues (last updated Feb 13 2007)

These are the currently open issues organized according to category.

Character set fixes/support

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

[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.

[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.

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.

[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.

New feature requests

[https://issues.apache.org/jira/browse/EMAIL-35 EMAIL-35]: Allow [DataSources] to be directly embedded in [HtmlEmails]. Patch available.

[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.) I'll look into this option.

Build fixes/enhancements

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

[https://issues.apache.org/jira/browse/EMAIL-63 EMAIL-63]: Submitted maven 2 pom.xml.

[https://issues.apache.org/jira/browse/EMAIL-64 EMAIL-64]: use a different test email server from a live project, not a dead one.

Release Plan

A commons-email 1.1 release is in the planning stages.

  • No labels