 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
1 message in org.apache.james.mailet-apiMailet changes (Was: 2.3.x vs trunk)| From | Sent On | Attachments |
|---|---|---|
| Stefano Bagnara | Mar 5, 2008 2:40 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Mailet changes (Was: 2.3.x vs trunk) | Actions... |
|---|---|---|
| From: | Stefano Bagnara (apa...@bago.org) | |
| Date: | Mar 5, 2008 2:40:03 am | |
| List: | org.apache.james.mailet-api | |
Noel J. Bergman ha scritto:
Robert Burrell Donkin wrote:
i think that moving the mailets into a separate project should make things move managable.
In the long run, I agree. Even in the mid-term, we can compare the Mailets in the new project with those in the release, and validate the changes.
I agree this should be done. We have a mailet project and changes between mailet v2.3 and current trunk mailet are minor.
a single consolidated library can used for both 2.x and 3.x releases (as
well as trunk).
We'll may have to make some changes to allow that, since people didn't treat the code in a manner that would ensure this simple statement. This would be another benefit from your proposal. Separating the Mailet library from the server would discourage people from changing them in lockstep.
"people didn't treat the code.... "? Whom? What changes?
Every single change we did in trunk mailets has been discussed in the mailing list. Most changes we did from 2.2.0 to 2.3.0 was to make sure some JAMES specific mailets could be made generic mailets (e.g: we moved some method from MailImpl to Mail in order to remove every cast to MailImpl in mailets).
Here is instead a list of changes between mailet released in 2.3.0 and current mailet trunk code:
GenericMailet - altered default logging to include mailet name + added checkInitParameters and arrayToString methods
GenericMatcher - altered default logging to include mailet name
MailAddress - constructor throws AddressException instead of ParseException - other changes by danny: http://svn.apache.org/viewvc?view=rev&revision=565772 http://issues.apache.org/jira/browse/MAILET-7
MailetContext - isLocalUser now expect a full email address. if no @ is there then @localhost is appended for the check. + added isLocalEmail
As you can see changes are very limited and maybe the only issue that should be better checked is the MailAddress compatibility. Every other change since 2.3.0 seems to be backward compatible (I would say both binary and source compatible)
That said, we want to be able to evolve the Mailet API, in a controlled and proper manner.
--- Noel
+1
we created mailet-api@ list, the mailet svn tree and the mailet jira because of this. Feel free to use one of this tools in order to discuss about your specific concerns about current mailet sources!
I cross post to mailet-api so we can continue there.
Stefano