Exception when trying to run LSA with Jama

[GoogleCodeExporter]

1. Add Jama jar to the CLASSPATH environment variable
2. Make sure you don't have svdlibc
3. Run lsa.jar and pass any text file and output directory as parameter

No exception is expected but one appears saying that svd program cannot be
run. The output directory is empty

Version:
LSA - 0.1.3
Jama - 1.0.2

Exception:
SEVERE: SVDLIBC
java.io.IOException: Cannot run program "svd": CreateProcess error=2, The
system cannot find the file specified
    at java.lang.ProcessBuilder.start(Unknown Source)
    at java.lang.Runtime.exec(Unknown Source)
    at java.lang.Runtime.exec(Unknown Source)
    at java.lang.Runtime.exec(Unknown Source)
    at edu.ucla.sspace.common.SVD.svdlibc(SVD.java:385)
    at edu.ucla.sspace.common.SVD.svd(SVD.java:231)
    at edu.ucla.sspace.common.SVD.svd(SVD.java:141)
    at
edu.ucla.sspace.lsa.LatentSemanticAnalysis.processSpace(LatentSemanticAnalysis.j
ava:388)
    at edu.ucla.sspace.mains.GenericMain.run(GenericMain.java:283)
    at edu.ucla.sspace.mains.LSAMain.main(LSAMain.java:122)
Caused by: java.io.IOException: CreateProcess error=2, The system cannot
find the file specified
    at java.lang.ProcessImpl.create(Native Method)
    at java.lang.ProcessImpl.<init>(Unknown Source)
    at java.lang.ProcessImpl.start(Unknown Source)
    ... 10 more
java.lang.UnsupportedOperationException: No SVD algorithms are available
    at edu.ucla.sspace.common.SVD.svd(SVD.java:248)
    at edu.ucla.sspace.common.SVD.svd(SVD.java:141)
    at
edu.ucla.sspace.lsa.LatentSemanticAnalysis.processSpace(LatentSemanticAnalysis.j
ava:388)
    at edu.ucla.sspace.mains.GenericMain.run(GenericMain.java:283)
    at edu.ucla.sspace.mains.LSAMain.main(LSAMain.java:122)

Original issue reported on code.google.com by andrejs....@gmail.com on 16 Jun 2009 at 1:30

[GoogleCodeExporter]

Confirmed the bug.  Starting work now.

Original comment by David.Ju...@gmail.com on 16 Jun 2009 at 8:07

• Changed state: Started
• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

It looks like the current issue is that the lsa.jar file doesn't include a valid
classpath reference to the JAMA .jar file (however it is named).  Because the 
LSA
class is running from within lsa.jar, the program's classpath is automatically
overriden by the jar Manifest, which prevents the reflective invocation.  (see
http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html for details)

We're looking into how to fix this automatically, but for now there's a work 
around.
Instead of:
  java -cp <classes> -jar lsa.jar <args>
use
  java -cp <classes>:lsa.jar edu.ucla.sspace.mains.LSAMain <args>

JAMA will work in this class, which is how we originally tested it.  The .jar 
fix
will come soon though.

Original comment by David.Ju...@gmail.com on 16 Jun 2009 at 10:36

[GoogleCodeExporter]

There's no easy way to specify a configurable classpath that contains the JAMA 
.jar
from within the lsa.jar Manifest file.  Therefore, we devised this solution 
where if
you run lsa.jar from the command line and you want to use JAMA, you specify the 
.jar
location with the jama.path system property.  So now your command line would 
look like:

java -Djama.path=<.jar location> -cp <classes> -jar lsa.jar <args>

The SVD code will pick up the .jar location and reflectively load the correct 
JAMA
classes.  The fix will be in lsa.jar version 0.1.4

The only other option that we saw was to include the JAMA .jar (or classes) in 
the
executable itself. We feel this is not as good of an option as it increases the 
.jar
size unnecessarily and it adds what should be an optional dependency.

If this fix doesn't work for you, please re-open this ticket and let us know 
what the
issues are.

Thanks for filing this!

Original comment by David.Ju...@gmail.com on 17 Jun 2009 at 2:45

• Changed state: Fixed

[GoogleCodeExporter]

Works for me. Great

Original comment by andrejs....@gmail.com on 17 Jun 2009 at 10:42