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
