lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Busby" <>
Subject RE: Lucene project announcement
Date Thu, 18 Nov 2010 01:06:07 GMT
Dear All,

I have not yet spoken up on this issue yet but I felt that I could not sit in silence any

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)


This is where the sense seems to end.   The "it must be a direct port of java stance" is completely

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.



-----Original Message-----
From: Troy Howard [] 
Sent: 17 November 2010 23:35
Subject: Re: Lucene project announcement


As you said, "If you're developing at the concept level the specific language you use becomes
unimportant. ".

This is exactly why we feel that working on this in C# is not a problem. We feel that the
language should not impede our ability to contribute. If we develop some interesting or valuable
concepts in C# those could be ported back to Java for inclusion in the Java implementation
of Lucene.

>From an implementation standpoint, we feel that the code should perform and integrate
as effectively as possible into the runtime it's in. Unfortunately there's no known software
runtime that executes concepts. They execute code written in a specific language. The details
of how that code executes and integrates into applications directly effects it's performance
and usability.

It's a disservice to the concept of Lucene to translate it literally, if doing so makes it
less performant or less usable.

Using human language as an example:

Consider the Chinese name for China:

?? (Zhong Guo)

translated literally it means "Middle Kingdom".

Imagine you were translating and important philosophical document from Chinese to English.
Would you translate "Zhong Guo" as "Middle Kingdom" or as "China"?

Suppose someone had asked the original philosopher to write all his ideas in English to start
because "English is the language of philosophy.. It's what all the eminent philosophers use".
Perhaps he would never contribute his ideas at all, since writing them down in English is
too great a barrier. Maybe he would write them down, but write them down in a way which made
them seem absurd or have less of an impact.. In other words.. Miss the meaning, even though
he'd translated literally.

Either way, it would be less ideal than simply writing them in Chinese to start, as that's
what would be most natural for our imaginary philosopher. The burden of translation from Chinese
to English could then be performed by an expert in translation, who would, undoubtedly, translate
the meaning conceptually, not the words syntactically.


On Wed, Nov 17, 2010 at 12:16 PM, Granroth, Neal V.
<> wrote:
> Is Java Lucene "grown up" ?  Look at how much discussion it took to 
> determine how to get Java out of the name :)
> The discussion about advancing the algorithm in C#/.NET seems to be missing the point.
 If you're developing at the concept level the specific language you use becomes unimportant.
 However as most of the concept developers apparently find Java convenient; others wanting
to participate at the concept level would find it more beneficial to join that brain-pool
instead of diluting the effort by starting up elsewhere.
> - Neal
> -----Original Message-----
> From: George Aroush []
> Sent: Tuesday, November 16, 2010 10:55 PM
> To:
> Cc:
> Subject: RE: Lucene project announcement
> This topic has been coming back again and again which I have tried to 
> address multiple times, so let me try again.
> 1) Java Lucene started years before the first C# version (4+ years if 
> I get my history right), thus it defined and has been the definer of 
> the technology and the API.  It is the established leader, and 
> everyone else is just a follower.
> 2) Lucene.Net is no were mature as Java Lucene, never got established 
> itself, or had a rich development community -- thus why we are here today.
> 3) If and only if, the community of Lucene.Net (or "Lucene" over at
> manages to proves itself to the level of Java Lucene, 
> only then such a community will have the voice to influence folks over 
> at Java Lucene.  Only then you will see the two community discussing 
> search engine vs. port issues or the state of Lucene.Net.
> If you look in my previous posts, I have pointed those out.  We must first:
> 1) Be in par with Java Lucene release and keep up with 
> commit-per-commit port.
> 2) Prove Lucene.Net is a grownup project with followers and a healthy 
> community (just like Java Lucene).
> If we don't achieve the above, folks over at Java Lucene will not take 
> us seriously, and thus we can't influence them.
> -- George
> -----Original Message-----
> From: Nicholas Paldino [.NET/C# MVP] 
> []
> Sent: Friday, November 12, 2010 10:36 AM
> To:
> Cc:
> Subject: RE: Lucene project announcement
> Paul, et al,
>        Paul, God bless you.  This is probably the most rational, 
> practical perspective I've seen on the whole matter since the debacle started.
>        While Lucene started off as a Java project, it's massive 
> success indicates that the concepts around it are very desirable by 
> developers in other technologies, and that the Java product isn't 
> being translated well into those technology stacks.
>        That's not a slight against those who have contributed to this 
> point to try and keep the .NET version in line with the Java one 
> (despite me thinking that the actual approach to doing so is a 
> horribly misguided approach).
>        That said, there should be a serious conversation with the 
> Java-version folk about making this happen.  How can Lucene be 
> abstracted/standardized in a non-technology-stack-specific way that 
> other technology stacks can create implementations against that 
> abstraction/standard.
>        Is it too much to ask of the Java folk?  Perhaps.  After all, 
> they haven't done it yet and it doesn't seem like they see the need for this.
> This isn't an unjustified position; that project has a massive user 
> base and success which creates massive responsibilities to the project 
> that must be fulfilled.
>        If such a thing proceeds, this is what I'd like to see in such 
> an
> abstraction:
> - Technology-agnostic concepts used, down to the class level:
>        - Classes might be the one exception, they are near universal.
> However, this could be something like "entity"
>        - Properties - Java doesn't have properties, they have a 
> property convention.  .NET has the concept of a property, which 
> translates to a named getter and/or setter which can execute 
> additional code on either in addition to the assignment.
>        - Fields - Raw exposed data points.  Whether or not these 
> ^should^ be used is a different story, but there are some places where 
> they are used so a definition is needed.
>        - Methods - Functions/methods, whatever you want to call them, 
> we all know what they are.
>        - In the end, the names are not important as much as the 
> abstractions are, I think we all have an idea on what they are.
> - Right now, I don't have a problem with a class-by-class mapping, but 
> over time, whether or not class design was done to suit the technology 
> should be addressed, and ultimately abstracted out if this is the case.
> - Things like ^what^ is returned from methods or internal constructs 
> that are used to make guarantees about behavior and the like should be 
> abstracted out.  For example, in Lucene.NET we have the following (in 
> order to maintain a line-by-line port in most cases):
>        - A custom implementation of ReaderWriterLock.  There's no 
> reason for something like this.
>        - Accepting and returning arrays even when the elements in the 
> arrays are read only.  In this case, there should be hard definitions 
> as to whether or not an IEnumerable would be better, since .NET has 
> such great support for deferred execution now.  Of course, if you 
> ^need^ a materialized list at some point, then an array is fine, but I 
> imagine there are ^many^ places where deferred execution would be a huge boon.
>        - Transactional behavior on IndexWriter - I'd love to see this 
> interact with the Transaction framework that was put in with .NET 2.0.
>        I don't expect any abstraction that comes out (if one does) to 
> follow the above, it's just the things that stick out to me initially.
>        Moving on to other issues (the Java Lucene folk can tune out 
> here if they wish, but feel free to read on!).  First, I've seen 
> others on this list express a desire to make Lucene.NET more ".NET 
> friendly", on this point, I can't agree more.
>        However, there is massive disparity on what people consider 
> ".NET friendly"; does it mean wrappers around existing code, better 
> use of .NET technologies to implement internal functionality, or 
> ".NETifying" things like properties and the like?  All of those 
> suggestions (and some others I'm
> sure) have been posted at one point or another.
>        If Paul's idea of a Lucene "standard" was realized, then all of 
> this becomes a moot point.  For those that say "the Java version is 
> the standard", re-read the fourth paragraph, the part about technology-agnostic.
>        Now, while I don't feel my opinion about whether or not it is a 
> good idea for people to start their own projects to realize a their 
> vision of a more ".NET friendly" version of Lucene for .NET is 
> relevant, I will wish them well.
>        However what is saddening is the feedback that I've seen from 
> people on this list and in others projects workspaces towards those 
> projects which are.  NO ONE has the right to say "you should not do 
> that"; if that person wants to head up that project, so be it, they 
> are moving in the direction their conscience/heart/mind tells them to 
> go.  Just because you don't agree with it to be the best step forward 
> doesn't mean they have earned your indignation.
>        It's another thing altogether to say "hey, ^would you^ consider 
> doing the work here, as we could use your help", or something along 
> those lines, the key word being "would".  That's a request, "you 
> should" is a demand.
>        Unfortunately, that's not what is happening in and out of the 
> list and it's behavior that I hope is curbed immediately.
>                - Nick
> -----Original Message-----
> From: Paul Hadfield []
> Sent: Friday, November 12, 2010 3:14 AM
> To:
> Subject: RE: Lucene project announcement
> It feels to be that the problem is being approached a* about face 
> (i.e. the wrong way wrong).  Maybe it is the way that ASF works but do 
> the constraints of Java define "Lucene, or should it bigger than that? 
>  Should Lucene be a full text engine concept that can safely be developed in multiple
> I'm sure everyone would agree that it would be silly to have different 
> underlying file/data formats and it would definitely make sense that 
> the rules for processing should be the same.   But could the 
> developers behind Lucene.JAVA and Lucene.NET work together to define 
> an independent Lucene project and road-map, etc.  This could then be 
> developed in each language independently of each other and heaven 
> forbid, Oracle managed to destroy all that is good about Java then Lucene would continue
regardless, etc.
> However, if the above (dream?) could not be met, I can't see any way 
> other than keeping with a direct port in the short term.  Once it is 
> proven that Lucene.NET can keep up with the Java development, then it 
> might be possible to think about something other than a direct port. 
>  This would simply be because every Lucene.NET release is currently trying to catch up
with 'x'
> Lucene releases and it feels like anything other than a direct port 
> would make that nigh on impossible to determine what needs to be 
> implemented in the .NET version.
>  - Paul.
> -----Original Message-----
> From: Hans Merkl []
> Sent: 11 November 2010 21:53
> To:
> Subject: Re: Lucere project announcement
> Keep in mind that Java Lucene is being developed actively. Once you 
> start to optimize for .NET, it will become harder and harder to keep 
> up with future Java Lucene development.
> Whats does MPS do that may be useful for Lucene.NET?
> On Thu, Nov 11, 2010 at 14:54, Karell Ste-Marie 
> <>
> wrote:
>> I have done no other past contribution other than use the product,
>> Can I be reminded, once again, why we don't use the .NET Optimized 
>> approaches instead of doing a straight code-code port?
>> I understand that the whole purpose of the project is to be a Lucene 
>> port to .NET, but should we not at some point in time optimize more 
>> for .NET than just continue to try and port more Java to .NET code? 
>> From Scratch? Each and every version?
>> It seems to be that if that is the approach then perhaps it would be 
>> time better spent to look into a tool such as MPS
>> ( and then use the source java language 
>> through this which would product .NET code on the other side.
>> Or perhaps I've just managed to place a size-12 foot in my mouth 
>> because the current process is actually almost exactly this today?
>> Comments welcome...
>> Karell Ste-Marie
>> C.I.O. - BrainBank Inc
>> (514) 636-6655
> **********************************************************************
> --=Disclaimer=--
> This communication is to be treated as confidential and the 
> information contained in it may not be used or disclosed except for 
> the purpose for which it has been sent. If you have received this 
> communication in error, please destroy it immediately and notify 
> Any defamatory statements or 
> infringements of copyright or licenses by employees of Palmer & Harvey 
> McLane Limited are contrary to company policy. The company will not accept any liability
in respect of such a communication.
> Computer viruses can be transmitted by email. The recipient should 
> check this email and any attachments for the presence of viruses. 
> Palmer & Harvey McLane Limited accepts no liability for any damage 
> caused by any virus transmitted by this email.
> Palmer & Harvey McLane Limited.
> Company registered in England & Wales. Regd. No. 1874153.
> Regd Office P&H House, Davigdor Road, Hove, East Sussex, BN3 1RE.
> **********************************************************************

View raw message