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