On Fri, 14 May 2010, Christian Heimes wrote:
Am 13.05.2010 20:27, schrieb Andi Vajda:
Here is an idea that I think should work but I couldn't test it because
bobo
is built from maven and pylucene isn't.
Basically, the idea is that you must be really careful in not having Lucene
classes come from two or more different places:
1. build pylucene the usual way
2. build bobo by giving it the lucene jar files that are inside
pylucene's
lucene egg by setting the classpath accordingly:
$ CLASSPATH=`python -c 'import lucene; print lucene.CLASSPATH'`
3. build the bobo extension with jcc using the same classpath and by
_not_
using --jar or --include with any of the lucene jar files already
inside
pylucene's lucene egg, relying solely on the classpath for finding
lucene classes
4. Once all is built, you don't need to set any classpath in addition to
what the initVM() calls are already doing:
>>> import lucene; lucene.initVM()
>>> import bobo; bobo.initVM()
The bobo extension adds its classpath to what lucene's already setup
and finds the lucene classes there.
Again, I didn't test this because it's too much work to disentangle the
bobo
build from maven so that I can control where things are coming from.
You understand the bobo build better and can probably try this quicker.
Thanks for the suggestion, Andi! I'll try your suggestion on Monday. I hope
it's sufficient to create a working version of lucene + bobo-browse in order
to provide my co-worker Julian a foundation for his work on bobo-browse. But
I fear that it's not going to work. I carefully excluded any jar file from
the bobobrowse egg that is already part of pylucene (--classpath instead of
--include or --jar). The lucene class are probably wrapped because
bobo-browse references the classes in its jar file.
By the way I've created the Makefile for bobo-browse based on your Makefile
for pylucene. With your template and your good work it was trivial to create
the Python bindings. Thanks ;)
I've an idea how you can solve the inter-package issue. Is it possible to
create some kind of type interference for JCC types that point to the same
Java class (e.g. lucene.Query.class_ == bobobrowse.Query.class_)?
Ah, I see now the bigger problem. What you're really after in the case where
bobo would cause its own lucene wrappers to be generated is the ability to
import them from the lucene extension instead. For this, the symbols would
need to be exported and the C++ headers generated by jcc during the pylucene
build included in the lucene egg. I think this could be done. Give me a few
days to think about this... say via a new --import jcc commmand line option.
Andi..
