Split API, SPI and private classes into separate packages
Description
Activity
Emmanuel Bernard July 4, 2011 at 3:32 PM
right, I think will bring the right type-safety
Sanne Grinovero July 4, 2011 at 3:29 PM
Another question: FSDirectoryProvider and co used to be public before we introduced directory provider shortcuts (ram, filesystem, filesystem-master, filesystem-slave, infinispan).
Should we keep them public or move them to a impl package?
I think it's fine having them as impl. That's what they are after all. Also discouraging the direct class name usage might make it easier to add alternative variants and then swith default implementations at a later time for a specific type (like mapping "ram" to a different one at some point without switching classnames which would be awful)
Emmanuel Bernard July 4, 2011 at 3:20 PM
Another question: FSDirectoryProvider and co used to be public before we introduced directory provider shortcuts (ram, filesystem, filesystem-master, filesystem-slave, infinispan).
Should we keep them public or move them to a impl package?
Sanne Grinovero July 4, 2011 at 11:27 AM
I'd assume it's an SPI? Would be nice to have eventually an Infinispan managed caching layer, i.e. maybe to reuse the Hibernate core 2LC interface and available configured implementations.
Emmanuel Bernard July 4, 2011 at 11:13 AM
Is FilterCachingStrategy an API or an SPI
Details
Details
Assignee
Reporter
Emmanuel BernardComponents
Fix versions
Priority
Major
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)