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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
