I want to use Lucene version 1.4.3 and upgrade to the current SVN version later on. I was hoping if there is some way to use 'morelikethis' code in 1.4.3.
If someone could someone please extract a version of this file from source control that corresponds to lucene 1.4.3 or if this can file can be back-ported, it would be greatly helpful. Or, here are some 'guesses' to get around compilation errors using lucene 1.4.3. Please review if this correct (because I am not familiar with recent changes) 1. IndexReader.getFieldNames( IndexReader.FieldOption.INDEXED ) does not compile on 1.4.3, replace with IndexReader.getIndexedFieldNames( true )? 2. query.add(tq, BooleanClause.Occur.SHOULD) does not compile on 1.4.3, is this the same as query.add( tq, true, true )? Thank you -Hareesh All developers in the lucene group, you guys are awesome and it is a pleasure to work with this library. I have one small request, is it possible to make the archive of 'Contribution' section that corresponds to Lucene 1.4.3 release available online? -----Original Message----- From: Otis Gospodnetic [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 19, 2005 12:17 PM To: java-user@lucene.apache.org Subject: RE: Searching for similar documents You need to point to the new Lucene Jar (from SVN, not the 1.4.3) version. Otis --- Derek Westfall <[EMAIL PROTECTED]> wrote: > I've been trying to compile the .java into a .class and I am getting > the > error below. > > Any idea what I am missing? > > Thanks, > > Derek > > > C:\CFusionMX\wwwroot\WEB-INF\classes>javac morelikethis.java > -classpath > c:\cfusi > onmx\lib\lucene-1.4.3.jar > morelikethis.java:509: cannot resolve symbol > symbol : variable FieldOption > location: class org.apache.lucene.index.IndexReader > Collection fields = ir.getFieldNames( > IndexReader.FieldOption.INDEXED); > ^ > morelikethis.java:524: cannot resolve symbol > symbol : variable FieldOption > location: class org.apache.lucene.index.IndexReader > Collection fields = ir.getFieldNames( > IndexReader.FieldOption.INDEXED); > ^ > morelikethis.java:581: cannot resolve symbol > symbol : variable Occur > location: class org.apache.lucene.search.BooleanClause > query.add(tq, BooleanClause.Occur.SHOULD); > ^ > 3 errors > > > -----Original Message----- > From: Otis Gospodnetic [mailto:[EMAIL PROTECTED] > Sent: Saturday, July 16, 2005 7:52 AM > To: java-user@lucene.apache.org > Subject: RE: Searching for similar documents > > They should work with the version in SVN, as well as with 1.4.3. > > Otis > > > --- "Kadlabalu, Hareesh" <[EMAIL PROTECTED]> wrote: > > > Thanks Otis! > > > > Are there Lucene 1.4 compatiable version of these classes? > > > > Thanks very much > > -Hareesh > > > > -----Original Message----- > > From: Otis Gospodnetic > > To: java-user@lucene.apache.org > > Sent: 7/16/2005 3:30 AM > > Subject: Re: Searching for similar documents > > > > We've got this in Lucene's contrib/: > > > > $ ll > > contrib/similarity/src/java/org/apache/lucene/search/similar/*java > > > > -rwxrwxr-x 1 otis otis 30431 Jul 9 09:20 MoreLikeThis.java* > > -rwxrwxr-x 1 otis otis 3612 Mar 16 17:31 SimilarityQueries.java* > > > > Otis > > > > --- "Kadlabalu, Hareesh" <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > I am trying to build a search utility that looks for > 'similarities' > > > between > > > documents. > > > In other words, for every document listed as a part of search > > result > > > for a > > > phrase, I want to be able to list documents that are similar to > it > > > (but not necessarily match the same search criterion). For > example, > > > if my search for "Tomcat" returned "Tomcat installation guide", I > > > > want to write a utility that looks for all similar installation > > > guides that may or may not > > be > > > related to Tomcat. > > > > > > One approach I am thinking is to use term vectors. Algorithm: > first > > > extract the top X term vectors from the current document and > create > > > a > > Boolean > > > query > > > for those terms. Run it against contents of other documents (I > will > > > probably have to remove commonly used terms manually?). Resulting > > > > documents should be similar to the original one. > > > > > > I am wondering if something like this already exists or someone > has > > a > > > better > > > algorithm/solution. Or am I headed off in the wrong direction > with > > > this algorithm? Your advice is highly appreciated. > > > > > > Thanks > > > -Hareesh > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
