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] Trivial Update of "Email" by BenSpeakmon
Date Sat, 24 Feb 2007 01:09:35 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:
updated a wontfix issue

------------------------------------------------------------------------------
  
  ----
  
- = Recently fixed issues (last updated Feb 22 2007) =
+ = Recently resolved issues (last updated Feb 23 2007) =
  
  == Bug fixes ==
  
@@ -37, +37 @@

  
  ''(Added in rev 510704)'' [https://issues.apache.org/jira/browse/EMAIL-63 EMAIL-63]: Submitted
maven 2 pom.xml.
  
+ == 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.''
+ 
  = Open issues (last updated Feb 22 2007) =
  
  These are the currently open issues organized according to category.
@@ -45, +51 @@

  
  [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.''
+ ''(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.''
  
  == Build fixes/enhancements ==
  

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