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

Emmanuel Bernard emmanuel at hibernate.org
Wed Sep 8 12:05:12 EDT 2010


On 8 sept. 2010, at 10:35, Hardy Ferentschik wrote:

> Hi,
> 
> I was working on the issues around upgrading HSearch to Lucene 3.0  
> (HSEARCH-424).
> Before even thinking about utilizing any of the new Lucene features like  
> numeric fields and so on, we
> have to deal with HSEARCH-593 - the upgrade of the Solr analyzer framework.
> 
> We are using the Solr analyzer framework (a set of Lucene filters and  
> matching factory classes) within
> the HSearch specific @AnalyzerDef annotation. The problem is that the  
> latest release of Solr (1.4) is
> compatible only to Lucene 2.9 and there is no official release yet which  
> works with Lucene 3.0.
> 
> In fact Solr is now part of the Lucene source tree and I assume Lucene and  
> Solr releases will now happen
> together. The current 3.1 branch of Lucene contains the updated Solr code,  
> but there is no release date
> for Lucene 3.1 in the near future.
> 
> As a workaround I created a new maven module -  
> hibernate-search-solr-analyzers - in HSearch. I added the
> latest source from the 1.4 Solr release and then backported the changes  
> form the Lucene 3.1 branch to make
> the analyzer framework work with Lucene 3.0.2. This works, but there were  
> several issues.
> The Lucene code has moved on as well on the 3.1 branch and new classes got  
> introduced, for example CharTermAttribute.
> Other issues are CharArraySet and CharArrayMap which now take a Version  
> parameter as well. Some classes
> also have moved from Solr core to Lucene core. This means that backporting  
> becomes quite a bit more complicated.
> 
> This is really not a good position to be in from a maintenance point of  
> view for hibernate-search-solr-analyzers.
> The good news is that our additional hibernate-search-solr-analyzers  
> module would become obsolete with
> a release of Lucene/Solr 3.1. At this point we would have the possibility  
> to release a new version of HSearch
> depending just on the new Lucene/Solr release.
> 
> What I am wondering right now is:
> 
> - Does it make sense to introduce hibernate-search-solr-analyzers and  
> should we have a release with this additional module?

To me yes as we need a release with Lucene 3.0 soon.

> - If we release hibernate-search-solr-analyzers, should we really make it  
> obsolete once Lucene 3.1 is out or keep this module
>   as sort of buffer?

I'm inclined to the buffer approach.

> - 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

> - This is not the first time we are having problems with the Solr code.  
> Does it makes sense to fork the Solr code
>   and maintain or own version of the analyzer framework?
> 
> Right now I tend to say that we go for the hibernate-search-solr-analyzers  
> approach, but remove the module again once
> Lucene 3.1 is released. But what's your take on this?
> 
> --Hardy
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev





More information about the hibernate-dev mailing list