Tellier Benoit created JAMES-2703:
-------------------------------------
Summary: Deprecation after 3.3.0 - Removal after 3.4.0
Key: JAMES-2703
URL: https://issues.apache.org/jira/browse/JAMES-2703
Project: James Server
Issue Type: Task
Affects Versions: 3.3.0
Reporter: Tellier Benoit
Fix For: 3.4.0
In order to improve overall James development experience, I propose to do a bit
of post 3.3.0 cleanup.
The proposal is to mark the given components as deprecated now, then, if no
contributor shows up and give some love to these components, remove it after
3.4.0 release.
An associated vote will be started on the mailing list.
Here are the rationals:
- Some components are not exposed to end users and affect our ability to
refactor code.
- These components do not receive contributions
- These components are not well enough tested
- We introduced some components that are better at performing that very task
The components are:
## mailbox
- mailbox/cache
Unused, not tested, low code quality
End user will not be affected by this removal
## server/data
- SieveDefaultRepository
Read the filesystem to retrieve sieve scripts, read only, one file per user
This does not support sieve script management and rtequires dropping
manually the filesystem
Migration strategy: use SieveFileRepository & CLI to upload scripts
- MBoxFileRepository
Already deprecated, will target removal after 3.4.0
Use FileMailRepository instead. Data migration can be done with reprocessing
+ specific configuration
- JDBCRecipientRewriteTable
Already deprecated, will target removal after 3.4.0
Use another RRT implementation
- AbstractJdbcUsersRepository DefaultUsersJdbcRepository &
JamesUsersJdbcRepository
Already deprecated, will target removal after 3.4.0
Use another UsersRepository implementation
## mailets
Note: these mailets are leveraging some storage capabilities of mailbox or
server/data.
- AbstractRecipientRewriteTable
Already deprecated, will target removal after 3.4.0
The mailet is responsible for the rule storage. No tests.
Note that this would allow removing JDBCRecipientRewriteTable and
XMLRecipientRewriteTable.
Migration plan: add the rules in the standard RRT and use the classic RRT
mailet.
- JDBCAlias
Already deprecated, will target removal after 3.4.0
This mailet does the RRT. No tests.
Migration plan: add the rules in the standard RRT and use the classic RRT
mailet.
- UsersRepositoryAliasingForwarding
Already deprecated, will target removal after 3.4.0
This buggy mailet expects the UsersRepository to be also a
RecipientRewriteTable. Hopefully, we have no such freaks.
Otherwise behaves as the classic RRT mailet.
Migration: Replace in the configuration by the classic RRT mailet
- MailboxQuotaFixed, AbstractStorageQuota, AbstractQuotaMatcher
Not using the quota API, these matchers do full inbox scans on each
processed email.
It adds confiusion with the non-experimental well tests IsOverQuota
matcher, relying on the mailbox quota system.
No test, big hierarchy
Migration plan: Use IsOverQuota + quota APIs
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
