You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Tellier Benoit (JIRA)" <se...@james.apache.org> on 2019/08/02 07:18:00 UTC
[jira] [Resolved] (JAMES-2703) Deprecation after 3.3.0 - Removal
after 3.4.0
[ https://issues.apache.org/jira/browse/JAMES-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tellier Benoit resolved JAMES-2703.
-----------------------------------
Resolution: Fixed
See JAMES-2701 for removal
> 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
> Priority: Major
> 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.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org