[ 
https://issues.apache.org/jira/browse/JAMES-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16926302#comment-16926302
 ] 

Tellier Benoit commented on JAMES-2703:
---------------------------------------

See https://github.com/linagora/james-project/pull/2679 for removals after 3.4.0

> 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
(v8.3.2#803003)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Reply via email to