We have several occurrence of those, for good reasons:
* “Extension” interfaces leaking into DSLs: extensions declare methods that rely on SPI types because they are intended for the engine and users should not use those, just provide an instance that is exposed through another API
* “MetadataContributor” leaking into SearchMappingRepositoryBuilder: SearchMappingRepositoryBuilder is provided by users to the MappingContributors which in turn will have to use SearchMappingRepositoryBuilder#addMapping. The only alternative would be for SearchMappingRepositoryBuilder to provide the MappingContributor to users to begin with, but that would prevent us from passing non-standard parameters to the contributor’s constructor, such as the SessionFactory in HibernateOrmMappingContributor
* “BeanResolver” leaking into SearchMappingRepositoryBuilder: BeanResolvers are definitely not implemented by users, but it’s users that choose a BeanResolver and configure it…
Note: as of HSEARCH-3140, the leaks are displayed when building with the {{jqassistant}} profile ({{mvn clean install -DskipTests -Pjqassistant}}).
We need to figure out what to do in those cases… Allow the leaks? Remove them somehow?
* {color:red} DECISION: See comments {color} * |
|
