Re: [hibernate-dev] [HSEARCH] package split in API/SPI/private aka HSEARCH-746
2011/5/11 Hardy Ferentschik <hardy(a)hibernate.org>:
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 see my wording wasn't very clear. I meant to say that Query only
needs #getDocumentBuildersIndexedEntities() in a single test - no need
at all in the main code for the SearchFactoryImplementor.
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.
Maybe we could remove the lowest level interface, so that real low
level has to deal with the implementation. I'm +/-0 about it, ok we
have a bit too many interfaces stacked but they look useful.
I could add an additional module - or reuse the integration-tests - to
actually depend on infinispan-query and run a smoke test; this won't
add any circular dependency but might give immediate feedback on
breaking Query during a test run, might make you more relaxed in
changing anything around this interface stack as it would provide
quick feedback on what's ok to do. The drawback would be when we
actually agree we need to break it, we'd need to a bit more work.
Sanne
--Hardy