On Tue, 11 Mar 2008, Bill Janssen wrote:
Have you seen this code, from
<http://forum.java.sun.com/thread.jspa?threadID=300557&start=45&tstart=0>?
No, but if this works I could compile into JCC by default when --shared is
true to make env->setClassPath() work.
Interesting, thanks for the link.
Yes, I think it's the way to go. This code is from April 2007, and
putatively Java 6.
Thinking about all this, I think the usage pattern might be as follows:
import jcc
jcc.initVM(maxheap='2000m', ...)
import lucene
jcc.extendClassPath(lucene.CLASSPATH)
import anothermodule
jcc.extendClassPath(anothermodule.CLASSPATH)
Almost. initVM() still needs to be called, and the jcc module need not be
imported. It is important to invoke the initVM() method of the module you're
importing since it contains code specific to that module to initialize
some of its classes. Then, it calls the initVM() C++ function in the jcc
shared library. Hence:
import lucene
lucene.initVM(lucene.CLASSPATH, maxheap='2000m', ...)
import anothermodule
anothermodule.initVM(anothermodule.CLASSPATH)
Here's another feature request: I'd like to be able to say "--jar
BigJar.jar", but not have the classes in it stubbed,
What do you mean by 'stubbed' ?
Andi..
except for the
ones which I specifically nominate. Using "--jar" has the side-effect
of bundling the jar file with the generated module, which is what I
want. It could be a different flag, "--bundle <jarfile>", which has
the effects of putting the argument on the classpath, and adding it to
the module.
Bill
_______________________________________________
pylucene-dev mailing list
[email protected]
http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
