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<[email protected]>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

Reply via email to