Why not joining the Lucene.Net team?

Nov 11, 2010 at 9:11 AM

Hey guys,

why don't you join your effort with the Lucene.Net team and spend your time with helping the official version of Lucene for .NET?


Nov 11, 2010 at 10:31 AM


We hope that the community doesn't see the two projects as mutually exclusive.

Basically, there are very good reasons for Lucene.Net to remain on it's current course. Many people support the idea of having a purely syntactic port from Java to .NET, and so far, that project, and that idea has been wildly successful. 

One of the main reasons I felt the need to start this project is that I struggled with the question of "What should Lucene.Net do? Should it change and be more like .NET or stay all Java-like?"... In the end I realized that both directions are equally valid. That implies that both concepts deserve their own project and team. 

We're trying to fulfill the community's desire (need?) for a Lucene implementation that makes sense in .NET, but we don't think Lucene.Net should stop doing what it's doing in order to fulfill that need. Instead, we started a new project for that purpose. 

With regarding to "resource management" (where the reosurces are the developers in the community that might want to contribute to a .NET implementation of Lucene)....There seems to be a lot of people in the community that are willing to donate their time, code, or just ideas... Lucene.Net doesn't have to be the only project for that. We feel that there's enough interest to support more than one project. So our work here will hopefully not be "taking away" from Lucene.Net and even if we are successful in making a awesome library, it wouldn't mean that Lucene.Net's library wouldn't remain useful.. Just different tools for different problems. Lucene.Net is a great tool for the problem it solves. We hope to make a great tool for solving all the problems it doesn't yet solve.

And who knows... Maybe someday the two projects will merge, share code, or otherwise collaborate and integrate. 




Nov 11, 2010 at 11:05 AM

Personally speaking, if Lucere.Net reaches the same level of stability and functionality on Lucene.Net I see no reasons why I should stick with the ugly java-like APIs of Lucene.Net.

Maybe I misunderstood, but it seems to me like they are not "different tools for different problems": they the different API to solve the same problem. If not, where is Lucere.Net different from Lucene.Net (other then the API)?

But I understand why you did this: the main contributors of Lucene.Net don't want to go to more .NET-like API and seems difficult to work out with the current super-impositions of the ASF


Nov 11, 2010 at 12:46 PM

Not to discourage you, but I think this is a big mistake. Lucene is such a big codebase that in my view it will be extremely hard to keep up with future developments. Look at all the other Lucene ports like CLucene or Pylucene. They all seem to have stopped development.

I'd rather see that effort gets put into the automatic porting tools, be it Sharpen or IKVM.

It would be nice to have more .NET like APIs but with the available resources I think it will be impossible to stay in sync with the Java Lucene version.


Nov 11, 2010 at 3:57 PM

Some of the other .NET OSS projects such as NH also started as ports but now have a conventional .NET API and use all the features that the .NET framework has to offer. So there is no reason to believe that the Lucere project can't, though I must say I  don't have a whole lot of experience using Lucene to comment intelligently

Nov 12, 2010 at 3:05 AM


The reason I say Lucene.Net is a different tool for a different problem is that they are solving the following problems that we will not be attempting to solve:

- Timely releases that are in sync with the Java Lucene project

- Exactly the same API which allows .NET users to take advantage of the Java Lucene resources (like code samples, books, and the Java Lucene community) or prior experience with Java Lucene

- 100% functional equivalence (bugs and all) with Java Lucene


The problems we're solving that Lucene.Net is not solving are:

- Staying modern with the API

- Take advantage of special features of .NET environment which do not exist in Java

- Involving more community members as committers (whereas Lucene.Net is limited by ASF's restrictions)

- Decoupling the architecture to make it more flexible


Our approach will make us slower to release. We are ok with that. 

Our approach may introduce differences in how our library works and what it supports vs. Java Lucene/Lucene.Net. We hope that these differences with be features and enhancements, not bugs. ;)

Our approach will end up requires more mental overhead to translate between code written in Java that does the same thing as code written against our API.

Our approach will require more work from users who are attempting to port a Java application that uses Lucene to .NET (but I would suggest that they use Lucene.Net in that case anyway).


So there are benefits on both sides of the coin. We aren't going to sweat our weak points and we aren't going to discount Lucene.Net's strong points. We're just going be an alternative platform which may be more useful in certain situations that Lucene.Net. 




Nov 12, 2010 at 3:06 AM



I appreciate your perspective, but we are optimistic about our ability to both re-write the library and stay up to date on a reasonable schedule. 

As for effort in other areas, you may be interested in the aimee.net project that was just started or simply follow and get involved with Lucene.Net. We've choosen this methodology, but in no way do we think it's the only or best way to go about bringing Lucene to the .NET platform. 




Nov 25, 2010 at 8:06 AM

I really like the idea of this project, as I actually attempted something similar on my own about a year ago. I didn't take a very structured approach and never got to the point of showing it to the public, however. I look forward to tracking Lucere's progress and perhaps contributing in any way that I can.

I do have two suggestions/requests, if these haven't already been considered:

1. Regardless of how the API might evolve, the actual index files (or at least relatively recent versions of such) should remain compatible with the Lucene.Net and Java Lucene format.

2. It would be very nice to have indexing and querying designed work correctly in a medium trust environment (e.g. GoDaddy) without any fragile hacks. This would make Lucere an ideal choice for use with all kinds of other projects that have the same requirement.


Nov 25, 2010 at 12:40 PM

Hi James,


The Lucere team have mentioned they plan to "retain file-level compatibility with all other Lucene implementations". See Troy's e-mail here: http://groups.google.com/group/lucere/msg/cfedc3e3b1717934




-- Paulo