...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="2133d64c296e4b91-7ea16267-442f4aed-8b2d8940-8be16a9e0942cbafc25506f2"><ac:plain-text-body><![CDATA[ | http://jakartacommons.apache.org/commons/email/images/email-logo-white.png | [http://jakartacommons.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://jakartacommons.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://jakartacommons.apache.org/site/mail2mail-lists.html#Commons mailing lists]. | ]]></ac:plain-text-body></ac:structured-macro> |
...
| Wiki Markup |
|---|
The current status (updated 1110/20062007) is available through SVN \[http://svn.apache.org/repos/asf/jakarta/commons/proper/email/trunk/STATUS.html here\]. |
...
. The 1.1 release has been approved and announced. The Commons community welcomes those who wish to drive the project further. |
...
Release Plan
No current plan is active as the 1.1 release has been approved and announced.
...
Archived discussion of 1.1 changes
This section contains notes on the reasoning behind the 1.1 fixes and waived changes so that other developers can use it as a starting point for their work.
New features
| Wiki Markup |
|---|
_(Added in rev 545815)_ \[https://issues.apache.org/jira/browse/EMAIL-35 EMAIL-35\]: Allow [DataSources] to be directly embedded in [HtmlEmails]. |
...
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
| Wiki Markup |
|---|
\[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:
...
(BenSpeakmon) This could be made better as detailed in the issue – I took a crack at it, but it turned out to touch a lot of moving parts to the point where I felt uncomfortable doing it in a point release. If anybody wants to use this as a starting point for a 2.0 release, possibly based on the contributed code, feel free 