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

[Hardy Ferentschik]

On Thu, 09 Sep 2010 12:45:35 +0200, Sanne Grinovero  
<sanne.grinovero at gmail.com> wrote:

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

Not sure if I follow you here. Let's take an example:



import org.apache.solr.analysis.GermanStemFilterFactory;
import org.apache.solr.analysis.LowerCaseFilterFactory;
import org.apache.solr.analysis.SnowballPorterFilterFactory;
import org.apache.solr.analysis.StandardTokenizerFactory;
... // non Solr imports

@Entity
@Indexed
@AnalyzerDefs({
		@AnalyzerDef(name = "de",
				tokenizer = @TokenizerDef(factory = StandardTokenizerFactory.class),
				filters = {
						@TokenFilterDef(factory = LowerCaseFilterFactory.class),
						@TokenFilterDef(factory = GermanStemFilterFactory.class)
				})
})

After renaming the packages the example would look something like this:


import org.hibernate.search.analysis.GermanStemFilterFactory;
import org.hibernate.search.analysis.LowerCaseFilterFactory;
import org.hibernate.search.analysis.SnowballPorterFilterFactory;
import org.hibernate.search.analysis.StandardTokenizerFactory;
... // non Solr imports

@Entity
@Indexed
@AnalyzerDefs({
		@AnalyzerDef(name = "de",
				tokenizer = @TokenizerDef(factory = StandardTokenizerFactory.class),
				filters = {
						@TokenFilterDef(factory = LowerCaseFilterFactory.class),
						@TokenFilterDef(factory = GermanStemFilterFactory.class)
				})
})


How would I be able to keep backwards compatibiltiy? The Solr classes are  
not loaded dynamically by us, but
explicitly referenced in the import statements.


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

You mean we should behave differently depending on which version of Lucene  
gets added to the classpath?
How do we set this up? Could we have multiple search artifacts using  
maven's qualified mechanism? (just
speculating here)
Or are you talking about multiple development branches?


--Hardy