Does not compile with Lucene 3.0

[GoogleCodeExporter]

semanticvectors does not compile with the most recent Lucene version (3.0)
as it uses classes that have been deprecated and abandoned since version
1.2.2. This is the case for both the released version of semanticvectors
and the svn trunk.

Original issue reported on code.google.com by johann.petrak@gmail.com on 24 Oct 2009 at 12:59

[GoogleCodeExporter]

I've fixed this problem (in svn, not released yet), for Lucene 2.9. Here the 
problem
is that Lucene 2.9 doesn't expose MMapDirectory, so I've changed to FSDirectory 
in
IncrementalDocVectors. (We were already doing this in VectorStoreWriter.)

However, I haven't found a Lucene 3.0. Is there one and if so could you send me 
a link?
Otherwise we should released a new version of SV saying that this is fixed for 
Lucene
2.9.

Original comment by dwidd...@gmail.com on 25 Oct 2009 at 10:31

• Changed state: Accepted

[GoogleCodeExporter]

Released a fix in version 1.24.

Still don't know of a Lucene 3.0, though.

Original comment by dwidd...@gmail.com on 3 Nov 2009 at 10:00

• Changed state: Verified

[GoogleCodeExporter]

Im also now experiencing problems with this, should i install an earier lucene
version to get this working. i get errors when i follow instructions saying:

> java pitt.search.lucene.IndexFilePositions index

Exception in thread "main" java.lang.NoSuchMethodError:
org.apache.lucene.analysis.standard.StandardAnalyzer: method <init>()V not found
    at pitt.search.lucene.IndexFilePositions.main(IndexFilePositions.java:36)

Original comment by drmaxlwi...@gmail.com on 15 Jan 2010 at 12:34

[GoogleCodeExporter]

You're right, I just replicated this problem.

I can't see an immediate way of getting SV to work with the FSDirectory in 
Lucene 3.0 
and 2.*. One has "open()" and one has "getDirectory()". Grrr.

I'll start with a message to the list alerting people.

Original comment by widd...@google.com on 15 Jan 2010 at 3:34

• Changed state: Accepted

[GoogleCodeExporter]

If this problem is still open, can you use Java Reflection to interrogate the 
object
to see which method is present? If so, if "open ()" is present, use that, else 
use
getDirectory ().

Original comment by classiclightphoto@gmail.com on 5 Apr 2010 at 3:22

[GoogleCodeExporter]

A conditional swiched on Java Relfection is a possibility, but not a nice one. 
Code
that has conditionals saying "if this interface is available, use this; if that
interface is available, use that ..." could easily become buggy and hard to 
maintain.

If we have to, I guess we could push this conditional into one 
"OpenLuceneResource"
method in LuceneUtils? Then at least it would be in one place in the codebase. 
What
do you think?

Original comment by widd...@google.com on 5 Apr 2010 at 3:30

[GoogleCodeExporter]

I agree that this kind of code is not the ideal theoretically and even 
practically, I
hate working with code that is bifurcated in this way all over the place. So I 
do
like the possibility of only having it exist in one, higher-level place. I 
mainly saw
my suggestion as a quick fix given the changes in the Lucene interface. If it 
were
me, I'd leave a significant note to myself to take out the 'if' as soon as 
Lucene
drops support for their older interface. In the mean time, I have a review 
meeting on
Friday where I want to show the Semantic Vectors package and using a pre-3.0 
version
of Lucene is inconvenient for other reasons. Thank you.

Original comment by classiclightphoto@gmail.com on 5 Apr 2010 at 5:47

[GoogleCodeExporter]

There are 37 errors when trying to compile the current source against Lucene 
3.0, and 
I think I'll veto the idea of maintaining this many conditional imports and 
dependencies.

I'm going to write to the list, say that we intend to update to Lucene 3.0 post 
haste, 
and if anyone wants to stay working with Lucene 2.x, they just can't use the 
most 
recent SV distributions. 

Original comment by widd...@google.com on 6 Apr 2010 at 8:32

[GoogleCodeExporter]

Update: refactored to be compatible with Lucene 3.0.1. Everything appears to be 
working correcly, except for the TermPositionVector and TermFreqVector 
interfaces in 
TermTermVectorsFromLucene. Trevor has also found that these behave differently 
with 32 
and 64 bit JVMs.

We're working on fixing this: in the meantime, if you need Lucene 3.x 
compatibility 
and are't worried about positional indexes, if you checkout and compile the 
source it 
should work OK.

Original comment by widd...@google.com on 8 Apr 2010 at 7:42

[GoogleCodeExporter]

We think this is fixed thanks to Trevor's StandardAnalyzer fixes in
http://code.google.com/p/semanticvectors/source/detail?r=354

We'll test some more in the next few days to make sure and make a new release
sometime next week (week of April 12th).

Original comment by dwidd...@gmail.com on 11 Apr 2010 at 2:37

• Changed state: Fixed

[GoogleCodeExporter]

Thanks so much for the quick work on this! I noticed that the deprecated enum 
symbol:
'Version.LUCENE_CURRENT' is still being used in code that I recently downloaded 
(e.g.
pitt.search.lucene.LuceneSearch). Should these be changed to 
'Version.LUCENE_30' in
the newest code in agreement with the comment from Apr 06, 2010? Thanks again.

Original comment by classiclightphoto@gmail.com on 14 Apr 2010 at 2:09