Hi community, I will probably very soon start the James 3.4 release process.
Before tagging the release, I'd like to propose some deprecations and removal for a vote. That way, deprecated components could be annotated just before the tag and it would let 3.4 users know what will disappear next. 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 3/ Spring 3 Spring is used as a Dependency Injection framework to allow maximum flexibility for the end user: one can just edit some xml to choose for the combination of component she/he wants. It relates to the Hexagonal Architecture I described in an earlier email. Being able to choose can be a good thing however, as a community, we decided in the recent years that we would provide supported combinations of technologies rather than idealistic everything-is- possible Spring xml way of building products. That's why we invested a lot in compile-time Dependency Injection with Guice: we built products (combinations of components that make sense) and we run testsuites against them to ensure at least some level of quality. It doesn't prevent anyone to choose a different combination of component but instead of xml files, she/he will have to create a Java class to declare the modules she/he wants and compile the whole thing. We are aware that we didn't explained that enough and that most people start using James with the spring product. So why would we deprecate it? The answer is straigforward: we use a very very old version of Spring and we probably will run into troubles maintaining it in the future. At the same time, recent Spring versions depart from the xml descriptors thing and would probably require a rewrite of the Spring modules entirely instead of an upgrade. Finally, there are features that only exist in the Spring product: support for maildir, dynamic loading of jars in general, etc. In conclusion, I would propose to deprecate that product starting with 3.4 version but target a removal in 3.6 to get enough time for users and devs to not loose important features. I do propose a vote to ensure consensus on it: - Answer this mail with "+1 for all decisions" to support all these deprecations - Answer this mail with "-1 for all decisions" if you reject the idea of removing components - Answer this mail with "+1 [decisions] -1 [decisions]" to express per decisions not favorable opinion. Negative votes should be motivated (and ideally have contributors for these components). Voting ends on 25th July 2pm UTC Regards, -- Matthieu Baechler --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
