lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George Aroush" <>
Subject RE: Lucene.NET Community Status
Date Thu, 04 Nov 2010 04:16:19 GMT
It's not impossible, it just takes time to become comfortable with the code
and the search engine.  I do not claim I'm a Lucene guru (I was with
SilverPlatter's SPIRT, and Dataware's BRS -- does anyone know those?! :-) )
Just like with any technology, it takes time to grok the internals.

-- George

-----Original Message-----
From: Ciaran Roarty [] 
Sent: Wednesday, November 03, 2010 2:14 AM
Subject: Re: Lucene.NET Community Status

Also, and this is a persistent theme in many people's emails, why is
there such a determined view that the search internals - the crown
jewels as described elsewhere - cannot be understood?

It may take a long time to innovate in that area but I can't see that
it is impossible.


On 3 Nov 2010, at 04:06, George Aroush <> wrote:

> Hi Everyone,
> Rather than responding to each email, I will write up one response.  The
> points is in no significant order or priority.
> 1) IKVM: Since it doesn't give you source code, you end up with Java look
> and fell, all the way from API to classes to exceptions.  If this is
> valuable option for your need, you can do it with ease; you don't need the
> support of ASF or Lucene developers.  Just use IKVM and off you go.  With
> this option, you are now further away from .NET'nes that's being asked of
> Lucene.Net, but all exiting Lucene resources (books, examples, support,
> etc.) is available for you and you can have a .NET version of Lucene the
> Java Lucene is released.
> 2) Other conversion tools: Using other converter tools (beside JLCA which
> the one I'm familiar with) should be looked at.  Keep in mind that until
> when they are tried out, and their quality is analyzed, they are just
> another tools beside JLCA.  In addition, since those are different tools,
> the output C# code may not be consistent with exiting Lucene.Net code.  If
> so, this will cause issue if such a change is at the public API layer; the
> port will no longer be backward compatible (at API level) with existing
> clients.  My preference is to stick with JLCA, since I'm familiar with it
> and know have written scripts to highlight where it falls short.  However,
> would like to see others try out other tools and report back.  I would be
> really surprise to see any tool doing much better than JLCA because if
> a tool exist, there would be many ports of other Java projects.  In
> email, I will outline a use-case to test those other tools.
> 3) .NET'fying Lucene.Net:  If you really want this, just start a new
> at ASF or someone where else.  I really don't see Lucene.Net achieving
> anytime soon per reasons that I pointed out earlier and over the years on
> this mailing list.  If you start such a project, it shouldn't be called
> Lucene.Net because that new project will produce a C# Lucene which is no
> longer compatible with existing Lucene.Net clients as the public API will
> now diverge.  In addition, you will also lose, based on how deep .NET'es
> make your Lucene, existing available resources  about Lucene (web, books,
> mailing list, etc).  You will also need good knowledge of search engines,
> and the internals of Lucene to make this happen.
> 4) Adding a .NET'es layer: Have a look at the list of classes and APIs
> Lucene.Net has to offer (see:
> -- hmm, looks like I never
> created doc for 2.9.x).  Do you plan to cover them all?  Only part of it?
> Are you ready to support it?  If so, you can start such a project at ASF
> somewhere else.
> 5) Support VS 2010: This is a minor issue (if an issue at all).  Just open
> the existing project and VS 2010 will ask you if you want to convert it.
> Personally, it's always best to support the lowest common compiler,
> environment and .NET Framework.  This way, you can support a wider
> as possible (even mono).  Remember, not everyone wants the source code, or
> can use the latest compiler or IDE, most just want the release DLL.  Java
> Lucene has always supported older ver. of Java till Lucene 3.0.
> 6) Lucene.Net on ASF:  This is a big one.  Many corporation and
> organization, big and small, will use and ship ASF software over other
> source software with very little, if any, reservation.  The license model
> ASF, the opens, brand reorganization and the process that ASF demands of
> project is well known and sound.  When you grab an ASF project, which has
> gone through incubation and graduated, you know you are getting a software
> which has been well vetted, is backed with a team that knows about the
> software, and the team will be around to back it up and support it.  At
> there is a established process which all graduated projects fallow.
> Lucene.Net, since it graduated, has NOT stood up to this level of
> Heck, there was only 1 official release back in 2006 of Lucene 1.9 which
> pre-graduation.  This is why Grant has raised this issue, to send us back
> into incubation or attic (retire).
> 7) Committers: There are several committers, few are more dedicated and
> active than others.  I was the initial and sole committer since 2004 (even
> prior to that on  This change since 2008 when we added
> DIGY, Doug and Michael; they all have contributed -- they took my initial
> port and cleaned up open issues.  When folks are saying there is 1
> committer, I think they mean to say there is only 1 committer who has done
> the initial ports.  Let us not forgot to give credit where it's due.
> 8) Not .NET'fying Lucene.Net and line-by-line port:  I want to say few
> things about this even though I pointed them earlier, but just to make it
> clear.  While it is true Lucene.Net doesn't have the full fell of .NET'nes
> (it's more like the first and second generation of C#) the fact that
> Lucene.Net fallows this port model means you can post a question on Java
> Lucene mailing list and everyone will know what you are talking about.  It
> means if there is a bug in Lucene.Net, you can debug it by doing a
> side-by-side run of Java and C# Lucene (no need for deep Lucene or search
> engine expertise).  It means existing Lucene resources are available for
> you.  It means a bug in Java Lucene also exist in Lucene.Net.  It means a
> rock solid Java Lucene is what Lucene.Net will be.
> 9) Back to incubation:  The reason to go back to incubation is mainly to
> make sure the ASF brand that a graduated ASF project is stamped with,
> to ASF's core.  As is, since Lucene.Net was prompted into graduation, has
> failed on this front.  As I pointed out earlier, there hasn't been any
> official release other than the one I did way back in 2006 for 1.9.
> ASF to offer Lucene.Net as a "graduated" and "stable" project does
> to existing graduated ASF projects not to mention the brand ASF.
> 10) Comparing this project to X:  You can look hard and deep to find
> why Lucene.Net isn't as successful as project X.  My take on it is, unlike
> other most successful open source projects, on ASF or somewhere else,
> Lucene.Net has NO active and continues committers who actually get paid to
> work on it.  Until when we have a sponsoring entity, any cycles or effort
> spent on this project by anyone is going to be an after though even if you
> are a dedicated user who is in need of Lucene.Net -- you will most likely
> commit a fix or a port to mainly get your need done.  This is also true
> a sponsoring entity, but the sponsoring entity has a broader need.
> 11) Lucene contrib:  I don't know how many folks know this, but I also
> ported a number of Java Lucene contrib codes.  Check the ported list:
> So where do we go from here?   Unless if there are further discussions or
> questions, I suggest we put our energy and effort on getting actual
> done.  To do so, I will start a new email thread on this subject sometime
> tomorrow.
> Thanks,
> -- George

View raw message