I agree with Sanne regarding the hiding of Solr framework behind an adaptor or whatever, even better if it'd possible to provide Solr integration as a separate module in HS (ex. hibernate-search-analyzers.jar), so that if someone wants it, just add the right jar, and Solr analyzers won't prevent the migration of Lucene version, which IMHO it's more important.
Gustavo On 9 Sep 2010, at 11:45, Sanne Grinovero wrote: > it's not clear to me what was decided, but *if* you decide to change > the packages, backwards compatibility will be broken anyway, so this > raises the doubt if we could just avoid supporting these analyzers at > the moment. > > So if you choose for renaming the packages, it should be done in some > way to prevent other breakages in the future: > All the mess we had about the "compress" value disappearing could be > avoided if we avoid exposing Lucene/Solr packages to the users; this > is happening again as they can point to the Solr class implementation, > so we could (either or): > > A) point out that we can't guarantee backwards compatibility in external > classes > > B) avoid having the user point to a non-HS class > > So if the Solr packages are renamed, I'd do it once and for all, > pointing to delegators we could fix in case of need, or as we do > control the class loading ourself, we could "translate" the requested > package name to the new one? So you might actually rename the packages > AND keep backwards compatibility - not sure if that's doable, but sure > it might seem weird to receive a different class than the one asked > for, the reflection loader should apply this trick only if it's able > to detect that it would load an incompatible package, so that in > future people can drop in a fixed up to date Solr and get the classes > they asked for. > > Final provoking thought, why is it so important to switch to Lucene 3? > couldn't we support both, and have people try to understand that if > they want backwards compatibility they should use Lucene 2.9 and if > they want Lucene 3 they won't be able to use Solr analyzers, pointing > to the fact that a compatible Solr wasn't released yet? > > Sanne > > 2010/9/9 Emmanuel Bernard <emman...@hibernate.org>: >> >> On 8 sept. 2010, at 18:23, Steve Ebersole wrote: >> >>> On Wed, 2010-09-08 at 18:05 +0200, Emmanuel Bernard wrote: >>>> On 8 sept. 2010, at 10:35, Hardy Ferentschik wrote: >>>> >>>>> - So far I haven't renamed any package names. This has the advantage our >>>>> existing users don't have to change their code. >>>>> Does it make sense to rename the packages? >>>> >>>> That's the big question to me. Feedback welcome. I could go either way. >>>> Pro: existing users don't have to change them >>>> Con: >>>> - we steal Solr's package which could conflict with people using Solr + >>>> HSearch >>>> - if we do a Solr integration one day (floating idea), we will have to do >>>> something in the area >>> >>> The general approach I like is to deprecate[1] the existing >>> classes/interfaces and "gut them" into classes/interfaces in the new >>> package, having the originals extend the newly packaged ones. >>> >>> ymmv >>> >>> [1] I prefer marking the stuff as @Deprecated as well adding log >>> warnings, as appropriate, in their constructors to let users know. This >>> lets users update/migrate at their "leisure" to an extent while still >>> being able to try out your latest/greatest. >>> >> >> Yes the annoying part is that this piece of code is not in our hands, It's >> the Solr APIs, so we can't deprecate them. >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
