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

[Steve Ebersole]

Well technically I define an SPI as anything Hibernate consumes to 
perform a function on its behalf.  Essentially anything that users, 
frameworks, app servers, etc "plug in" to Hibernate to tell it how to 
handle certain things.  The contract for that would be an SPI.

Notice this covers Type/UserType, because again its something Hibernate 
consumes even though a user might provide (implement) it.

API = Application Progamming Interface (the interface, or contracts, an 
application uses)
SPI = Service Provider Interface (the interface, or contracts, that 
define provided services (function behavior)

I tend to think of it in terms of "usage diagram" as that is the most 
convenient for me.  The user app sits on top and interacts (interfaces) 
with Hibernate.  That defines the API.  "Underneath" Hibernate is a 
series of contracts for telling Hibernate to do deal with databases, or 
transactionality, or caching, or...  These each define an SPI.

That is how I do it for core.

On 05/10/2011 12:29 PM, Emmanuel Bernard wrote:
> I've started the work to split classes between API, SPI and private classes.
> Some areas went very well, some are more problematic but that was to be expected. Anyways it did generate a couple of questions from philosophical to concrete. Please try and chime in.
>
> 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.
>
> An aternative approach is to mix the two definitions:
>   - 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).
>   - any API targeted at frameworks integrating with Hibernate Search are SPIs For example SearchConfiguration and SearchFactoryIntegrator would be SPIs
>
> But then we lose the distinction between framework APIs and user APIs.
>
> What do you think?
>
>
> 2. Specific issues:
> o org.hibernate.search.batchindexing.impl.Executors is used by MutablefactoryTest
> should we keep executors as private or should we consider it an actual API or SPI?
>
> o Should built-in types be public APIs/SPIs?
> I was tempted to put some if not all as private classes but there are use cases where these classes are used by actual users:
>   - the programmatic API (ProgrammaticSearchMappingFactory uses them)
>   - provided id settings
>
> Should we consider some / all as public classes? For example what about ClassBridge?
>
> o Is NumericFieldUtils a public class? It is used by NumericFieldTest, ProjectionQueryTest but it seems a user should not use this helper class
>
> o SearchConfiguration is very likely an SPI which means we will need to break Infinispan's query module, is that OK?
>
> o Programmatic API
> *Mapping objects are messed up with *Descriptor objects
> It seems to be that *Descriptors should be private while *Mapping should be API, do you think it's worth working on this? The programmatic mapping si still considered experimental so we have some time I guess.
>
> 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?
>
> That's all for now but more will come :)
>
> Emmanuel
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

-- 
Steve Ebersole <steve at hibernate.org>
http://hibernate.org