[
https://issues.apache.org/jira/browse/JAMES-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810487#comment-16810487
]
Tellier Benoit commented on JAMES-2703:
---------------------------------------
I am glad to announce you that the following proposition had been accepted.
- Votes for: +5 with a quorum of 3 PMC
- Votes against: 0
See the following pull request:
https://github.com/linagora/james-project/pull/2293
Related mailing list thread:
https://www.mail-archive.com/server-dev@james.apache.org/msg60016.html
> 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.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
