Hi, 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. I do propose a vote to ensure consensus on it: - Answer this mail with "+1 for all components" to support all these deprecations - Answer this mail with "-1 for all components" if you reject the idea of removing components - Answer this mail with "+1 [components] -1 [components]" to express per component not favorable opinion. Negative votes should be motivated (and ideally have contributors for these components). Voting ends on 4th April 9am UTC Here are the rationals: - Some components are not exposed to end users and affect our hability 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 See associated ticket: https://issues.apache.org/jira/browse/JAMES-2703 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 of 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. Otherwize 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 --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
