Took me longer than expected but here is a raw version
http://fisheye.jboss.org/changelog/Hibernate?cs=14524&csize=15
Hibernate Search reuses Solr analyzers.
@Entity
@Indexed
@AnalyzerDef(name="customanalyzer",
tokenizer = @TokenizerDef(factory =
StandardTokenizerFactory.class),
filters = {
@TokenFilterDef(factory =
ISOLatin1AccentFilterFactory.class),
@TokenFilterDef(factory =
LowerCaseFilterFactory.class),
@TokenFilterDef(factory =
StopFilterFactory.class, params = {
@Parameter(name="words", value= "org/hibernate/search/test/
analyzer/solr/stoplist.properties" ),
@Parameter(name="ignoreCase",
value="true")
})
})
public class Team {
@Id
@DocumentId
@GeneratedValue
private Integer id;
@Field
private String name;
@Field
private String location;
@Field @Analyzer(definition = "customanalyzer")
private String description;
...
}
On Mar 11, 2008, at 22:36, Chris Hostetter wrote:
: > 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
