George Thanks for your comments. I don't want to reply to all of them and make the email completely unreadable so I will try to sum up my thoughts and see where we go from there.
I think we have conflicting views of what a 'pure' Lucene.Net is and I'd like to make my case more clearly as I cannot imagine that you would have a problem with it. Lucene.Net will always be driven by Lucene as the community around Lucene is mature and developing at pace compared to Lucene.Net; this is not a criticism, it is a fact of life. What I don't understand is how that development is progressing - i.e. what features are being added, what features are being removed, if performance is being improved...... I presume you have a far better understanding of those realities. Now, Lucene.Net is a fully functioning, very performant, extremely useful component / library / product. I cannot emphasise how important Lucene.Netwas in developing a viable search strategy for a project I was working on recently. However, I wanted the library to be a .NET 2.0 library; not just compiled under .NET 2.0.... I have an aversion to ArrayLists, for example, and I'd like them to be replaced by Generic Collections. So, to achieve these two aims: keeping up with Lucene and making Lucene.Netmore .NET 2.0 specific, I think we have to prove the process..... By that, I mean we need to take a Lucene.Net release - I suggest 2.1 - and branch the codebase. What this allows us to do, is to revise the Lucene.Net release without affecting Lucene.Net's ability to move forward with Lucene enhancements and improvements whilst - in a low risk environment - learn the lessons of making Lucene.Net 'purer.' Does that make sense? Basically, I am happy with the functionality in Lucene.Net just now and I think it would be a good thing to have an optimised, purer .NET 2.0 version of the library. I understand that the Lucene.Net / Lucene relationship should not be broken as Lucene is clearly still developing and we, as a community, can gain from this continued development. However, I think the community can also gain from the development of an optimised for .NET 2.0version of the library. That's my thinking. It is what I am truly interested in doing. I think the community would respond well to a version of Lucene.Net which is optimised for .NET 2.0 and I think we will struggle to do that with Lucene.Net alone as it necessarily follows Lucene developments. Thanks for reading, Ciaran On 03/04/07, George Aroush <[EMAIL PROTECTED]> wrote:
Hi Ciaran, Please see my comments below. Thanks. -- George Aroush > -----Original Message----- > From: Ciaran Roarty [mailto:[EMAIL PROTECTED] > Sent: Monday, April 02, 2007 6:44 AM > To: [email protected] > Subject: Lucene.NET Pure [was 'Lucene.Net project involvement'] > > Hi > > I just want to check some facts and see if I have picked up > the right emphasis from the majority of the posts. > > Firstly, Lucene.NET 2.1 is due to be released soon. Yes, Lucene.Net 2.1, a first cut release should be out by end of this week or over the coming weekend. Btw, it's "Lucene.Net" and not "Lucene.NET" > Secondly, the port of Lucene to Lucene.NET is not an > automatic process and George does post-migration work > currently to bring the JLCA work closer to the .NET world. > > Using the Lucene.NET effort, people on this list have gone > away and made the port of Lucene into a purer .NET version. > These changes have, however, stayed internal to their work > and they have not been backported. Are you sure about this? I have not read anyone saying this. What folks have said is that they eliminated unnecessary exceptions from the Lucene.Net code; exceptions that also exist in the Java version and were brought over to C# via the port. There is a JIRA issue about this and we had a long discussion about it on this mailing list some time ago. The folks on the Java mailing list knew about it and fixed it for 2.1 release. > When I asked the question about getting involved in the > project and making Lucene.NET 'purer' - in a .NET sense - > then there appeared to be a real desire to get involved with > that process. It was also noted that this would need to be a > manual process; I suggested that the next major release - > Lucene.NET 2.1 - should be the basis for this work. > > Therefore, I think we should branch the code at 2.1 and work > on that branch. > In that way, we do not stop the progress of Lucene.NET in > line with Lucene but we do get to make some .NET optimisations. I disagree about branching off a new baseline. Like I said in a previous posting, the first thing we need to do is bring up Lucene.Net to be in part with the code base of what's in the Java Lucene SVN with what's in the C# Lucene SVN. Once we achieve this important but difficult milestone, and most importantly we prove that we can maintain it, then we can start looking at the existing code base and make the code .NET 'purer'. > Lastly, I believe that .NET 2.0 was the preferred platform > for this work and that it would be ok to use .NET 2.0 > specific capabilities. Yes, the work on Lucene.Net 2.1 will be release .NET 2.0 specific; but again, our first goal must be that we get in par with Java's Lucene SVN before we diverge the code into more .NET. > Does that sound right? Any builds on this? Any problems with > the approach? > > Thanks in advance, > Ciaran Roarty >
