On 26 Jan 2014, at 20:52, Sanne Grinovero <sa...@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
