On 8 sept. 2010, at 10:35, Hardy Ferentschik wrote: > - 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

On 8 sept. 2010, at 18:23, Steve Ebersole wrote: > On Wed, 2010-09-08 at 18:05 +0200, Emmanuel Bernard wrote: >> On 8 sept. 2010, at 10:35, Hardy Ferentschik wrote: >> >>> - 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 > > The general approach I like is to deprecate[1] the existing > classes/interfaces and "gut them" into classes/interfaces in the new > package, having the originals extend the newly packaged ones. > > ymmv > > [1] I prefer marking the stuff as @Deprecated as well adding log > warnings, as appropriate, in their constructors to let users know.  This > lets users update/migrate at their "leisure" to an extent while still > being able to try out your latest/greatest. > Yes the annoying part is that this piece of code is not in our hands, It's the Solr APIs, so we can't deprecate them. _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

I agree with Sanne regarding the hiding of Solr framework behind an adaptor or whatever, even better if it'd possible to provide Solr integration

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.

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?

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&gt;: > On Thu, 09 Sep 2010 12:45:35 +0200, Sanne Grinovero > <sanne.grinovero(a)gmail.com&gt; 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 > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

So we still load the class, and also try to invoke it's default constructor, but if we fail we try loading the alternative.

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?

On Wed, 08 Sep 2010 18:05:12 +0200, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: >> - 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. But what does buffer mean in this case? Just copying the latest Solr code (hopefully without modifications in this case) into our module. Or remove all code and use our analyzer module to just add another transitive dependency to Solr 3.x (or whatever the version will be)?