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

[Sanne Grinovero]

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
>