Re: [hibernate-dev] [HSEARCH] package split in API/SPI/private aka 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?
I don't think exposing this as SPI is very useful to people, but at
some point in future it's possible we might want to make this a
replaceable component, to let the AS (for example) provide threads and
monitor them.
Even if it's private, wouldn't our tests still be able to use it?
sure. BTW I interchangably used private for impl (sorry about that)
>
> 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
Can't we keep stuff in .impl packages but not necessarily private?
sure, I did not mean Java private but in an impl package, sorry about that. But still,
such a sue would be a "warning" to users as they should not use impl classes.
>
> 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
Having something like NumericFieldUtils is useful to write numeric
queries, but it doesn't necessarily have to have the current API. I'm
fine in hiding it and suggest people to use the DSL, and eventually
add a better helper later on if needed.
>
> o SearchConfiguration is very likely an SPI which means we will need to break
Infinispan's query module, is that OK?
I'ts definitely and SPI. what do you mean by breaking Query? if you
only want to move it to a different package that's not an issue; if
you want to change the exposed methods please suggest how and I'll
check with Query if that is arrangeable.
yes I mean package move