What I mean is that when you read the annotation having
@TokenizerDef(factory = org.apache.solr.analysis.StandardTokenizerFactory.class)
you could try starting it, but if it doesn't work you do
factory.getName().replace("org.apache.solr",
"org.hibernate.search.analysis")
and then use the new one loaded by reflection, after spitting out a
fat warning about the fact that you're messing with it, and that the
user will get a different class than what he asked for.
If the "translated name" points to a non-existent class, something
else is wrong.
Sanne
2010/9/9 Hardy Ferentschik <hibernate(a)ferentschik.de>:
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