directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: OSGI and Interface vs classes separation
Date Tue, 18 Oct 2011 14:08:43 GMT
On 10/18/11 3:52 PM, Göktürk Gezer wrote:
> Hi Emmanuel,
> On Tue, Oct 18, 2011 at 3:59 PM, Emmanuel Lecharny<>wrote:
>> Hi,
>> 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.

I tend to think the same thing.
>> 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.
We may allow users to define their own specific SyntaxCheckers for 
AttriuteType they will add. IMO, we should make them 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".

So we should provide a bundle contaning interfaces for partitions and 
interceptors, is that what you mean ?

Could be core-api...

Emmanuel Lécharny

View raw message