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 "Matthieu Baechler (Jira)" <se...@james.apache.org> on 2019/08/21 14:36:00 UTC
[jira] [Commented] (JAMES-2870) Handle 3.4 deprecations and
removals
[ https://issues.apache.org/jira/browse/JAMES-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16912341#comment-16912341 ]
Matthieu Baechler commented on JAMES-2870:
------------------------------------------
The OSGi part has been handle by [~BTellier] here https://issues.apache.org/jira/browse/JAMES-2857
> Handle 3.4 deprecations and removals
> ------------------------------------
>
> Key: JAMES-2870
> URL: https://issues.apache.org/jira/browse/JAMES-2870
> Project: James Server
> Issue Type: Task
> Reporter: Matthieu Baechler
> Priority: Major
>
> After a vote organized on the server-dev mailing list, we decided to mark as deprecated the following components:
> > 1/ zookeeper-seq-provider
> >
> > This module allows to generate sequence numbers for things like IMAP
> > modseq or uid. It has been implemented to fulfil the lack of support
> > for this kind of feature in HBase.
> >
> > Cassandra has the same kind of problems, as most distributed
> > database, but we solved the problem without requiring yet another
> > complex middleware.
> >
> > As HBase is no longer part of the codebase and to my knowledge the
> > component is not used anywhere else, I propose to mark it as
> > deprecated for 3.5 in order to target a removal for 3.6.
> >
> > 2/ OSGi (karaf)
> >
> > Maven contains some code and the build configuration to generate
> > some OSGi bundles.
> >
> > I have personnaly no interest in OSGi nor extensive knowledge about
> > it and as far as I know, no active developer on the project is able
> > and/or willing to maintain that.
> >
> > I didn't tested any James OSGi thing and I suspect that it has bit
> > rot with years to the point it's not usable at all.
> >
> > I will probably propose some Java Module support in the future to
> > gain back some interesting features of OSGi (not exporting every
> > classes of a Module, declaring proposed services and required ones,
> > etc) but in the meantime I think that we have no interest keeping
> > that code around.
> >
> > I thus propose complete removal before 3.4 release
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org