commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jakarta-commons Wiki] Update of "Email" by BenSpeakmon
Date Tue, 13 Feb 2007 23:55:50 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" for change notification.

The following page has been changed by BenSpeakmon:
http://wiki.apache.org/jakarta-commons/Email

The comment on the change is:
Added list of current open issues with status and my recommendation.

------------------------------------------------------------------------------
  
  || 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]. ||
  
- = Project Status =
+ = (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 =
  

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message