On Friday 16 March 2007 10:47, Jos van den Oever wrote:
> > Clucene has a copy of the classes, and you depend on strigi having an
> > exect copy of the code to make it all work.
> > You said clucene will not change it copy of the classes any other way
> > from strigi. ÂNow, if you did get hold of that one crystal boll and can
> > predict the future, we are friends. :) If not we should follow the normal
> > rules of maintainable code and that includes minimizing dependencies.
> This dependency on the same files is only in Âthe _implementation_ of
> the cluceneindex directory.
So, there is not a copy f the classes in both projects?
> This is not different from any other
> library dependency. Our API does not depend on what clucene does. If a
> future version of clucene changes the api, we change only the
> implementation when we want to use that version.
I'm confused; you can't make the clucene engine to compile if the API of
strigi is different from the api of strigi. That is the current state of
Your answer states thats not the case. If you are right, then please alter the
API implementation of the clucene engine to discouple the two
Or, lets turn it around. Strigi should alter the implementation of the
classes (Like InputStream) in several aspects;
* namespace should be Strigi
* classes should use a d-pointer
* we should avoid having getFoo() methods in those classes.
So, instead of waiting for clucene to alter the headers and then fixing the
implementation of the engine, please do it now.