: > Basically I would like to provide the configuration front-end and
: > initialization to the Solr classes through Hibernate Search annotations and
: > have a loose dependency on the Solr JAR (or maybe a trimmed down version of
: > the Solr JAR). This will help avoid any code fork or duplication. From what
: > I've seen quickly, the analysis package is pretty well isolated from the
: > rest of Solr. Minus TokenizerChain, both TokenizerFactory and
: > TokenFilterFactory are public APIs in Solr.

I'm not sure what you mean by "Minus TokenizerChain..." ... TokenizerChain 
is also public.

>From a technical standpoint this seems like a great idea to me.  the 
Tokenizer and TokenFilter Factories are not only public APIs, but also 
well documented "plugin" APIs, so you can expect Solr to support them 
as well as the corresponding Base*Factory classes for a fairly long time. 

One thing you might have to worry about in the long run is satisfying 
the dependencies of concrete implementations of those Factories that might 
get commited into the solr code base (tendrals into other Solr 
internals might creep in) but within the Solr Dev community we've talked 
about trying to minimize that in the long run (hence the ResourceLoader 
and ResourceLoaderAware APIs) so hopefully it won't be a big concern for 
you.  (If anyone ever gets the gumption, the bulk of the schema related 
code in Solr might even someday get promoted out of Solr into a 
contrib of Lucene-Java)

: > technically (your lights are more than welcome), but more broadly with the
: > concept of "code borrowing".

I have no problem with it ... I've never personally used Hibernate Search 
but I know the right tool for the right job when I see one, and being able 
to write one analysis Factory and know that it can be reused in both Solr 
and in Hibernate Search would definitely make some people I know very 
happy.



-Hoss

Reply via email to