On Thu, 09 Sep 2010 12:45:35 +0200, Sanne Grinovero
<sanne.grinovero(a)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