lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Karich <>
Subject Re: Lucene project announcement
Date Thu, 18 Nov 2010 14:33:25 GMT

>  A) make a great Java to C# porting tool

db4o has already something like this, I think.
maybe the guys from db4o would give lucene committers a license?
or would it be bad to rely on none free tools like this?

or maybe there is already an equivalent tool?


> I'm forced politely disagree with some of these thoughts, let me explain why:
> I order for this technique to be successful it seems that there is as much work being
poured into the porting technique as there is with the port itself. To my point of view it
does seem like this is double the work for benefits that are perhaps not as good as they could
be (I am not saying in any way that Lucene.NET today is not good, it is quite good and is
the results of great efforts from a lot of very dedicated people) since it follows a java-style
design which is great of the java world, but perhaps not always optimal for the C# world.
The project should be doing one thing, either:
> A) make a great Java to C# porting tool
> B) make a great search engine in C#
> As an example, it would be a hair-pulling experience to take Lucene.NET as it is today
and use it on Microsoft Azure, an environment that is specifically designed for .NET applications.
> As I said before, besides using Lucene.NET itself I haven't contributed much and only
in discussions - I haven't committed any code. However I will say this: I personally don't
know nor care about the Java language just as I'm sure many of you don't care about Prolog.
In order to help out, I feel that I need to be able to read and understand the Lucene version
in order to make the same stuff happen in the Lucene.NET version. This means I have to be
both a Java and C# developer at the same time?
> Mathematicians have been using math to explain algorithms for years, it is a universal
language that is (to different levels) understood by all.
> How those functional algorithms are implemented in a imperative language makes no difference,
so long as they are implemented and produce the intended result.
> I think that in the end, there should be at least 3 projects for Lucene:
> 1. The Lucene algorithms, in a platform-neutral language - let the search engine gurus
implement how this should be done without having to worry about imperative programming and
the hacks to get there - either a compiler or a manual model would be used to implement these
> 2. Lucene - Architecture of the project(s) - perhaps a lot of UML here in a format where
it can be fed to quickly produce skeleton files
> 3.x. Lucene - language-specific versions
> As Grant points out it is up to the community to make a decision, then let's all get
together and see if collectively a decision can be made.
> And for the record, I personally think that when an open source project has 3+ ports
to the same language - there is a problem. What that problem is however, I won't venture in
taking any guesses.
> I make these comments for the good of the project(s) and it is in no way my intention
to offend anyone and I salute all work and effort done thus far, we would not be here were
it not for everyone involved.
> Karell Ste-Marie
> C.I.O. - BrainBank Inc
> -----Original Message-----
> From: Alex Thompson []
> Sent: Thursday, November 18, 2010 3:58 AM
> To:
> Subject: RE: Lucene project announcement
> I don't think Lucene.Net staying a line-by-line port is craziness. We're not saying that
Lucene.Net is the one true implementation and there can be no others. I see Lucene.Net as
part of a spectrum of solutions.
> On one end of the spectrum is IKVM. If you want all the java lucene features immediately
and the constraints of IKVM work for your scenario then great, off you go.
> Then there is Lucene.Net. This is good if IKVM doesn't work for you, you want short lag
time behind java lucene (yes this needs improvement but we're working on it), and ability
to read java lucene books/examples and apply that relatively seamlessly to your .NET code.
> Then on the other end of the spectrum is the forks (wrapper/extension/refactor etc.)
that try to make things ideal for the .NET world.
> I think it's clear there is interest and support for both Lucene.Net and the forks. They
should both exist and be complimentary, not competitive. The forks provide greater flexibility
and greater exposure so more users and contributors can get involved. Lucene.Net provides
the benefits listed above and provides an avenue for features to trickle down from java lucene
to the forks.
> So bottom line there is no one-size-fits-all implementation. Lucene.Net (as a line-by-line)
provides good value to a significant user base and (assuming we can optimize the porting)
takes relatively little effort, so it is a useful part of the spectrum.
> Alex
> -----Original Message-----
> From: Andrew Busby []
> Sent: Wednesday, November 17, 2010 5:06 PM
> To:
> Subject: RE: Lucene project announcement
> Dear All,
> I have not yet spoken up on this issue yet but I felt that I could not sit in silence
any more.
> I completely understand the stand point of the current development team and agree with
the goals that they are setting out to achieve.
> Keep this index format compatible with the java version:  (check great work)
> Ensure that an search on a .net version will return the exact same results as the java
version: (check great work)
> But,
> This is where the sense seems to end.   The "it must be a direct port of java stance"
is completely craziness.
> I am not taking about the use of java conventions, I do not care if a have to get a value
using something with a prefix of "get", I am talking about not making the best use of the
tool at hand in this case .NET
> There also a clear indication that community  (maybe just the vocal ones) is saying we
want to help be feel we can't or are not inclined to.
> Open Source software is about enjoyment and a project that basically says if you want
to help just translate this code file from java to c#.
> Was this not a punishment at school? Translate this passage from Latin to English during
your break time!
> This whole discussion started because the project made an announcement that
we need help, it is not working.  It now appears that we are going to continue to carry on
using the same model, isn't the definition of insanity "continuing to do the same thing and
expect a different result".
> If you are going to be getting an automated tool to do the work great, is a community
even need? I doubt there will be much for anyone to get involved with, except fixing api conflicts
between nunit and junit which can probably be scripted anyway.
> I have seen several people rush out and create their own forks with big promises (I know
one of them is even being backed by would it not be better to try to channel
all of the energy of these people on to a branch, homed within apache which is the best place
for it and see what they come up with?
> It is a no lose situation, the current trunk will continue as is but something great
may appear that everyone is happy with and end this unrest.
> Before everyone shouts that people should be putting their efforts into the current truck
version, it is just not going to happen.  You cannot jump up and down and say that we are
in charge, you must commit our way (it says so on the web page) or your energy is not welcome.
>   I reality, watching the current events unfold, I cannot see much changing. Maybe one
or two new committers but most people will just wait for the new automated tool to get setup,
the java guys to fix the bugs and the tool to keep the versions up today or the current committers
get really "pissed off" at continuingly coming under fire and give up (worse outcome possible).
> Having said all of that, I just want to say thank you to all of the committer
that have got us to this point. Just should be proud of what you have achieved and that actually
do have a community that wants to see the project continue.
> Anyway just how I see things.
> Thanks,
> Andrew

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message