[hibernate-issues] [Hibernate-JIRA] Commented: (HSEARCH-746) Split API, SPI and private classes into separate packages

[Emmanuel Bernard (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=42674#action_42674 ] 

Emmanuel Bernard commented on HSEARCH-746:
------------------------------------------

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?

Sanne => keep un impl and let it be used by tests


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

=> impl


o SearchConfiguration is very likely an SPI which means we will need to break Infinispan's query module, is that OK?

=> right, SPI

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.

=> +1 let's do that, as you say not very urgent.

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.


> Split API, SPI and private classes into separate packages
> ---------------------------------------------------------
>
>                 Key: HSEARCH-746
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-746
>             Project: Hibernate Search
>          Issue Type: New Feature
>          Components: analyzer, directory provider, documentation, engine, integration, mapping, massindexer, optimizer, query
>            Reporter: Emmanuel Bernard
>            Assignee: Emmanuel Bernard
>             Fix For: 4.0.0.Alpha1
>
>
> API should go into a functionally named package
> SPI should go into a functionally named package .spi eg org.hibernate.search.bridge.spi
> private classes should go into a functionally named package .impl eg org.hibernate.search.bridge.impl
> Note that the distinction between API and SPI is a bit blurry and needs to be refined by the team as a whole:
>  - is it any "public" API not directly called by the user application (ie a Bridge would be SPI). That's the definition followed by the Hibernate Core team.
>  - is it any API targeted at frameworks integrating with Hibernate Search as opposed to APIs (eg SearchConfiguration)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira