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/03/28 08:27:00 UTC
[jira] [Updated] (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 updated JAMES-2703:
----------------------------------
Description:
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
was:
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
> 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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org