Re: [hibernate-dev] [HSEARCH] package split in API/SPI/private aka HSEARCH-746

> 1. > API vs SPI: > http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-746 > > I have a question on API vs SPI. > The Hibernate Core team uses the following rule: > - any "public" API not directly called by the user application is a > SPI (for example a Bridge would be SPI and I imagine BootStrategy would > be too etc). > > We could however sue a different rule: > - any API targeted at frameworks integrating with Hibernate Search > are SPIs For example SearchConfiguration and SearchFactoryIntegrator > would be SPIs but Bridge classes and BoostStrategy would not > > I'm tempted by the second definition as it separate user focused > classes from integration / framework focused classes. Of course nothing > is in back and white and some classes can be hard to categorize. +1, reasoning in next paragraph

> o SearchFactoryIntegrator vs SearchFactoryImplementor > In my mind, I introduced SearchFactoryIntegrator to separate private > SearchFactory usage from frameworks usage. > Does the Infinispan Query module depends on SearchFactoryImplementor > only? Or is it depending on SearchFactoryImplementor? It's built on top of SearchFactoryIntegrator, in some tests this is cast to SearchFactoryImplementor to be able to verify some state but I think you can ignore that. Currently Query needs only #getDocumentBuildersIndexedEntities(), in worst case we could expose that.