On Tue, Oct 18, 2011 at 3:59 PM, Emmanuel Lecharny <firstname.lastname@example.org>
today, I did a bit of cleanup in core-api and core-shared, moving what I have put in core-shared to core-api (most of the moved classes were associated with interceptors), and now, it raises a question :
- what should we do with core ?
I thing we must merge core-shared and core into core again, after separating Interceptor class references. When the core will access the interceptors through their name only, there won't be a need to have core-shared.
It's almost empty, only containing a few implementations (4 classes currently).
I remember that Alex has split core into core and core-api, to move all the interfaces into core-api and the implementation in core, and I guess it was to ease the OSGi implementation in the near future (AFAIR).
When I read about OSGi, it says that we should separate interfaces from implementations, and I buy this idea to some extent. I can understand that we should bundle all the public API in a separate bundle.
Now, the pb I have is that we have a bunch of classes in core-api, plus 28 interfaces. Why should we have all those classes in core-api then, instead of having only interfaces ?
What would be the best solution, OSGi-wise ?
Bundling interfaces into a core-api would be a good choice, if seperating core-api into 2 projects is not harmful. But as I get acquinted with the codebase, I see not so much reasons for doing it so. For that kind of interface bundling we must specify which of the features will be pluggable by clients and 3th parth developers. For example i see no reason for Normalizers,Comparators or SyntaxCheckers to be pluggable. But obviously the Interceptors and partition implementations must be pluggable that one may want to write his own, so we must provide the Interceptor and partition implementation related interfaces in one bundle. This is not necessary, but clean. This is just an ability to say "it is the bundle you'll reference to write an interceptor or partition implementation".