Search 6 groundwork - Use dedicated APIs for the ORM mapper instead of extending the POJO mapper APIs, where possible

Description

In some APIs in the ORM mapper, we've been extending the Pojo mapper directly. But it turns out we often had to override a lot of methods. See for example HibernateOrmSearchManager, HibernateOrmSearchTarget, ...

I'm a bit concerned that this will lead us to expose unnecessary methods in the ORM APIs, or to be unable to redefine some signatures (such as a method returning Optional<T> instead of Optional<Object>).

I think it would be safer, at least for 6.0.0, to define the ORM APIs separately as much as possible. We can continue to extend abstract classes from the POJO mapper where possible, and use delegation where it's not, but at least let's avoid exposing interfaces from the POJO mapper as APIs.

In some places we don't have a choice, of course, for example for bridges and similar classes. But there are other interfaces from the POJO mapper that can be hidden easily.

I (Yoann) started something on my branch: https://github.com/yrodiere/hibernate-search/tree/HSEARCH-3398

List of all APIs in the ORM mapper as of today (2018-10-17):

APIs from the POJO mapper:

Environment

None

Status

Assignee

Yoann Rodière

Reporter

Yoann Rodière

Labels

None

Suitable for new contributors

None

Feedback Requested

None

Fix versions

Priority

Major
Configure