lucene-pylucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <>
Subject Re: Problems passing PyLucene objects to jcc-wrapped bobo-browse api
Date Fri, 14 May 2010 02:24:00 GMT

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.


View raw message