1/ +1 2/ +1
3/ +1 overall however I believe we have to make improvements to the guice extension mechanism. Some example of things that would make sense: - As a user I want to inject dependencies non bundled in James for my extensions. I also think deprecation/removal of spring-only features should be done separately. Cheers, Benoit On 18/07/2019 15:12, Matthieu Baechler wrote: > 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, > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
