...

...

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 Feb

...

23 2007)

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 510704)_ \[https://issues.apache.org/jira/browse/EMAIL-63 EMAIL-63\]: Submitted maven 2 pom.xml.

Open issues (last updated Feb 22 2007)

These are the currently open issues organized according to category.

New feature requests

Waived features

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

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

Open issues (last updated Feb 22 2007)

These are the currently open issues organized according to category.

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-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 'll look into this option.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._

Build fixes/enhancements

\[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\]. subethasmtp's maintainer has no interest in putting the JDK 1.4-compatible version into maven, so we'll have to handle that.

...