So I just got the command line tool back to the level of functionality
it was at before I decided to switch to GCJ.
It can now run a search and print out the results, which required
implementing the code to retrieve a particular field from a document.
This was the last thing that was really needed to be able to usefully
run searches.
You still can't build queries programatically, but if you're willing to
create them with the query parser (which is what I imagine most people
will want to do) it is now possible to write code to run searches and
display the results.
Note that the interface for part of this stuff will likely still change
in the future. We're currently just returning an array of hits, this
will need to morph into a lcn_hits_t object, which wraps the underlying
org.apache.lucene.search.Hits object, so we can avoid pulling all the
results into memory at once. Still, it's enough to get started, and
adding the code to wrap the Hits object wouldn't be that hard if someone
wanted an excuse to dive into the code.
Another "bite sized task" would be to add indexing support to the
command line tool. I'd like to have a basic "index this directory of
crap" command, which would recursively go through the directory it's
given, adding each file it finds to the index, with the path as one
field and the contents as another, similar to the Lucene demo
application. This would allow us to flesh out the remaining indexing
functionality that is needed for useful work, since I'm positive there
are a few more bits and pieces that will be needed.
-garrett
it was at before I decided to switch to GCJ.
It can now run a search and print out the results, which required
implementing the code to retrieve a particular field from a document.
This was the last thing that was really needed to be able to usefully
run searches.
You still can't build queries programatically, but if you're willing to
create them with the query parser (which is what I imagine most people
will want to do) it is now possible to write code to run searches and
display the results.
Note that the interface for part of this stuff will likely still change
in the future. We're currently just returning an array of hits, this
will need to morph into a lcn_hits_t object, which wraps the underlying
org.apache.lucene.search.Hits object, so we can avoid pulling all the
results into memory at once. Still, it's enough to get started, and
adding the code to wrap the Hits object wouldn't be that hard if someone
wanted an excuse to dive into the code.
Another "bite sized task" would be to add indexing support to the
command line tool. I'd like to have a basic "index this directory of
crap" command, which would recursively go through the directory it's
given, adding each file it finds to the index, with the path as one
field and the contents as another, similar to the Lucene demo
application. This would allow us to flesh out the remaining indexing
functionality that is needed for useful work, since I'm positive there
are a few more bits and pieces that will be needed.
-garrett