Split API, SPI and private classes into separate packages

Description

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)

Environment

None

Activity

Show:
Emmanuel Bernard
July 4, 2011, 11:13 AM

Is FilterCachingStrategy an API or an SPI

Sanne Grinovero
July 4, 2011, 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, 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, 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, 3:32 PM

right, I think will bring the right type-safety

Assignee

Unassigned

Reporter

Emmanuel Bernard

Labels

None

Suitable for new contributors

None

Pull Request

None

Feedback Requested

None

Fix versions

Priority

Major
Configure