My opinion is that we should use reflection for that so we don't have to
introduce "imaginary.javax" packages/interfaces.
The best of both worlds would also be to have a workaround (based on the
md5 hash hack for each message we discussed before) for stores not
implementing this "method".
What do you think?
Stefano
Joachim Draeger (JIRA) wrote:
[ http://issues.apache.org/jira/browse/JAMES-461?page=comments#action_12412302 ]
Joachim Draeger commented on JAMES-461:
---------------------------------------
No, it isn't necessary to patch javamail. I don't think it's a big problem to
contribute that few, little but powerful methods to javamaildir.
The problem is how to access that methods because javamail nonsensically
doesn't offer such an interface (UIDPlusFolder). (But using that methods in the
class IMAPFolder)
I'm not willing to accept this seeming insuperable borders between Apache and
GPL. There is a good java implementation of maildir, we should use it.
In a worst case we could use reflection to avoid strong dependencies.
To clarify the original problem: When you store a mail in a javamail Folder, a
copy get's stored and it is not possible to find that copy again. So this
doesn't fit in James MailStore contract.
Maildir support
---------------
Key: JAMES-461
URL: http://issues.apache.org/jira/browse/JAMES-461
Project: James
Type: New Feature
Components: MailStore & MailRepository
Reporter: Norman Maurer
Fix For: 2.4.0
Attachments: JavamailStoreMailRepository.java, MaildirMailRepository.java,
MaildirMailRepository.java, UIDPlusFolderMailRepository1.zip
Add Maildir support..
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
