> > 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)
Perhaps the "extendClassPath" step could be automatic when "lucene" or
"anothermodule" is loaded, if the CLASSPATH for that module is non-empty.
In my case, I don't want to stub most of the classes for the jar file
I have to use, so I stub it with
jcc --classpath BigJar.jar --python goodstuff --version 1.0.0 GoodStuff
--build
which means that the BigJar.jar file isn't in goodstuff.CLASSPATH, but
is necessary for use. So my sequence would be something like
import jcc
jcc.initVM(maxheap='2000m', ...)
[...then at some other point in the code...]
import jcc, lucene
jcc.extendClassPath(lucene.CLASSPATH)
[...and in yet another place...]
import jcc, goodstuff
jcc.extendClassPath('BigJar.jar')
Here's another feature request: I'd like to be able to say "--jar
BigJar.jar", but not have the classes in it stubbed, 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
