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