OSGI and Interface vs classes separation

[Emmanuel Lecharny <el...@gmail.com>]

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 ?

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 ?

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: OSGI and Interface vs classes separation

[Emmanuel Lécharny <el...@apache.org>]

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<el...@gmail.com>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.

yes.

> 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...

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: OSGI and Interface vs classes separation

[Göktürk Gezer <go...@gmail.com>]

Hi Emmanuel,


On Tue, Oct 18, 2011 at 3:59 PM, Emmanuel Lecharny <el...@gmail.com>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.

>
> 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".

>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
> Regards,
Gokturk