Re: [hibernate-dev] [Search] OSGi split packages
On 26 Jan 2014, at 20:52, Sanne Grinovero <sanne(a)hibernate.org> wrote:
The classes in the ORM module are extremely widely used by our
primary target:
- FullTextQuery
- Search
- FullTextSession
and two more lesser ones, but I think the 3 above are probably "THE
API”.
That was my thinking as well.
To move these out of the way we'd at least need to postpone the
OSGi work for after a Beta to include a deprecated version of these.
? I don’t get what you are saying here. Deprecate it in an Alpha in order
to then move them in a Beta release? That makes no sense what soever to me.
My take on this is, that we are dealing with a new major version of Search
and that we are still in Alpha phase. If we need to make non backwards
compatible changes we should do it now.
Or we keep them around in the backwards compatible module
"hibernate-search” ?
For what? Making things even more complicated?
On the other option, in Engine we have:
- Environment (containing all the configuration constants)
- ProjectionConstants (more useful constants)
- SearchException
- SearchFactory (another strong case of public API)
Also to remember the changes in Engine also affect the HQL parser
(OGM) and Infinispan Query and its users; we can adapt for it but
ultimately that's our responsibility too, probably best to verify
early on to see the impact. Not really a reason to not do it, but it
has an impact on several other projects which we need to facilitate.
Mind you, we are talking just about an import statement change. No API
or functional change. And yes, our downstream projects would need to adjust.
I think I like Hardy's approach of moving from Engine better;
not
least we can provide alternative deprecated constants in the ORM
module for ORM users to use as a migration help (Environment and
ProjectionConstants).
?
To reply on the more fine-grained details:
> org.hibernate.search.Environment -> org.hibernate.search.cfg.Environment
since it's API, WDYT of a fully fledged mouthfull
“org.hibernate.search.configuration.Environment"
I like it. In fact I wish cfg would have been called configuration in the first place.
Having both, cfg and configuration seems odd to me. In this case I prefer to just
use cfg
> org.hibernate.search.SearchFactory ->
org.hibernate.search.spi.SearchFactory
as Emmanuel said, that's an API currently.
Right. I am not 100% happy with this choice either. Mainly moved it there, since we have
SearchFactory
related classes in there already (not all of which are api either)
I'm inclined to think we
should convert it to an SPI, and provide a richer more ORM specific
version in the ORM module?
Interesting. On the other hand, making SearchFactory an spi sounds strange to me.
> org.hibernate.search.SearchException ->
org.hibernate.search.exception.SearchException
Maybe making the package plural? We should add variations for specific failures.
+1 I was about to suggest that as well
> org.hibernate.search.FullTextFilter ->
org.hibernate.search.filter.FullTextFilter
"filtering" ? "filters" ?
Not too fond of the singular term as it's not very explicit (yes I
know it's an existing one).
I think I would stick with filter. I guess it comes down to how disruptive we want to be
> org.hibernate.search.Version ->
org.hibernate.search.engine.Version
+1
:-)
—Hardy