Antonello Provenzano wrote:
Erik Hatcher ha scritto:
On Jun 3, 2005, at 4:53 AM, Antonello Provenzano wrote:
I'm quite finishing the porting (a *proper* one) of the Apache
Jakarta project Lucene.
What version of Lucene did you port? How can you ever be "finished"
since Lucene is continually evolving?
I'm porting the version 1.4.3. I'm a developer as you are: I know
perfectly a software is always in-motion and cannot finish until it's
discontinued!
and would like it to be hosted and mantained: I have no time for
the development of the code. .
I have recently tested yet another technique for using Lucene in .Net
that resolves these two problems and others. I.e., with no effort I can
use the latest Java source code pulled from subversion, including all
patches in bugzilla. Also, it is possible to submit patches back to the
main java codeline. The approach is to use IKVM for byte-code
translation, leaving the source in Java. I tried this in both Microsoft
.Net and Mono. On the Microsoft platform, all unit tests passed except
for TestDateTools (and DateTools are only used by apps, not directly by
Lucene itself). The bug there turned out to be an issue in the Calendar
class in GNU.Classpath. I reported this and the Classpath guys have
fixed it, so as soon as the fix propagates to IKVM, all unit tests will
pass.
In Mono however, many tests fail. I think many bugs remain in Mono.
I've not done stress testing yet, but performance on the unit test suite
seems faster than in Java. Running the unit tests requires JUnit, which
ikvm's into .Net byte code without issue.
There are disadvantages to this approach as well, but the advantages of
access to latest code, zero effort, and participation in the Java Lucene
community are strong positives. Integration with Lucene from C#.Net is
not quite as good as the source code ports, e.g. names remain in Java
conventions, but otherwise integration is fairly seamless. The main
disadvantages are with debugging (e.g., can't step into Lucene from
C#.Net app in Visual Studio) and with reverse integration (can't easily
code a call from Lucene, e.g. a patch, into C#; it is possible to
subclass Lucene in C#). If one does Lucene patches and extensions in
Java, all works well. Plus, that allows for contributing them back to
the main codeline.
Ok... I pourposed the port to the #Dashboard community, being a Mono
developer: they suggested me to pourpose it to the Lucene community
too, saying you would be interested in hosting it.
Antonello, have you run the unit tests on your port in Mono? If that
works, it would be a most exciting development. Is your code posted
somewhere?
Anyway, the #Dashboard developers would be interested in the development.
Can you provide a pointer to these guys?
The implementation I downloaded and compared against is the dotLucene
(used by #dashboard and beagle too): I was unable to find the source
code for the George Aroush's Lucene.NET. Then, I contacted the author
of the dotLucene project, for replacing his code with mine. I'm still
waiting for an answer...
George has many tools that help to automate his port. Also, he has just
completed an initial port of the latest 1.9 code base, which some of us
need. What porting approach do you use -- how much manual effort is
involved?
Chuck
