[hibernate-dev] [HSearch] Upgrade to Lucene 3.0

[Gustavo Fernandes]

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 <emmanuel at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> 
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev