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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
