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

[Hardy Ferentschik]

See answers inline

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

+1 from me as well.
Still not convinced that this rigorous package naming is really a good  
idea,
but it seems we are committed.

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

I don't have much to say to the other points, but if we could get rid of
one of these I would give it a big +1.

--Hardy