Michael Fair points - I cannot see how we can ever have a pure .NET version if we continue to use the JLCA approach.
The question therefore is - do we want a pure .NET version or not? To answer that question I think we need to have an opinion on the following issues: - If we encounter an error in Lucene.Net - such as the boxing of bytes issue reported recently - do we go back to the Java codebase, fix the code, and then regenerate the code? My guess is that we don't; how dow do we preserve fixes over releases just now then? - Is there an intrinsic value in having a pure .NET version? - Do we have a Lucene.Net roadmap which runs in parallel to Lucene or do we just follow it? Now, bear in mind that I have not yet done any development of the Lucene.Netcodebase so I realise that I don't know the process as yet. Moreover, I have found the current Lucene.Net component to be one of the most effective, useful, pieces of software I have ever used. So, can I suggest an approach? What if we branched the code - at Lucene 2.1 - and investigated how we would go about taking that codebase and making it 'purer?' Treat it as a proof-of-concept....... And, if the approach works, we can develop a plan to do this for other Lucene releases post its release. Does that seem sensible? Ciaran On 28/03/07, Michael Mitiaguin <[EMAIL PROTECTED]> wrote:
Ciaran, What I can't understand if core of synchronising versions with Java Lucene is Java Language Conversion Assistant, how all this cleaning up/revising is going to work. Would it be possible to build automated procedure which preserve all .Net improvements after conversion from major upgrade from Java ? I am not sure. Even if to track somehow only changed/added Java classes still for each such class merging new/revised Java functionality with previous manual changes to utilise .Net capabalities is required. You used term component , but Lucene is rather API with fine grained classes and a simple change may propagate into several classes ( files in Java ) . I don't know how George is coping with that and what would be the plan if say tomorrow Lucene Java 3 will be realeased. Michael Ciaran Roarty wrote: > Michael > > I've been in touch with George about getting involved and he said to > post to > the mailing list. > > I reckon there's a fair amount of work could be done in changing the > codebase without affecting the published interface and I reckon that's > where > the bulk of the initial work would take place; as we know, the code is > not > yet optimised for .NET. > > Now, balanced against that, in my opinion are the following factors: > > - The code currently compiles against 1.1 and 2.0 (albeit with some > obsolence); any change to move Lucene.Net to 2.0 would leave the > 1.1codebase behind. > - There are different types of contribution to the codebase: cleaning up > code; revising methods and classes to benefit .NET standards and > capabilities is a good thing. However, Lucene is a powerful IR > component and > if the core development of those capabilities happens in the Java version > then we will need to follow that. > > That's my thoughts for the moment. Maybe we could take a specific part of > the component and revise that. Learning lessons about the process and the > codebase from that exercise, we can move into the guts of the > component...... > > Any thoughts? > > Ciaran > > On 27/03/07, Michael Mitiaguin <[EMAIL PROTECTED]> wrote: > >> >> Ciaran, >> >> The only active contributor to the project is George Aroush and perhaps >> he is the only person who will give you the most definite answer. >> I am also interested only in Net2/3 codebase . Currently vesion 2.0.4 >> still uses VS 2003 projects and my main concern are warning messages >> about deprecated and obsolete methods when compiled under Net2. >> Supposedly it 'll be fixed in 2.1 >> Also Java Lucene is more mature project with a lot of people involved >> and it would be safer to crosstranslate new things from there taking >> into consideration .Net specifics. >> From other hand in my case if Lucene will be part of a project where >> all warning messages considered to be the errors which must be >> eliminated , it it beyond my competency what can be done to achieve >> that. ( JavaCC generated code crosstranslation creates a lot of them ) >> >> Michael >> >> Ciaran Roarty wrote: >> >> > Anthony >> > >> > I too have used Lucene.Net with C# 2.0 to great effect. However, I am >> > discussing the use of .Net 2.0 in the codebase itself; and, if not, >> the >> > optimisation of the codebase for .Net in general. >> > >> > Ciaran >> > >> > >> > On 26/03/07, tony njedeh <[EMAIL PROTECTED]> wrote: >> > >> >> >> >> I set up my lucene to a .net 2.0 framework, using VB and it works >> >> well in >> >> that environment. >> >> >> >> Anthony >> >> >> >> Ciaran Roarty <[EMAIL PROTECTED]> wrote: >> >> George et al >> >> >> >> I have been using Lucene.Net in a proof-of-concept environment for >> the >> >> last >> >> couple of months - with my colleague Guy Steel - and we wanted to get >> >> involved in its development. >> >> >> >> I am a .NET developer for a large consultancy company and would >> like to >> >> get >> >> involved in making Lucene.Net more aligned to .NET and .NET 2/3 in >> >> particular. However, I am not sure if that is something which is >> >> initially >> >> planned for Lucene.Net. As I understand it, the majority of the >> >> conversion >> >> has been done, initially, using the Java Language Conversion >> Assistant. >> >> Some >> >> of the Java codebase uses patterns that are not best practice for >> .NET >> - >> >> such as using Exceptions for non-exceptional circumstances. This is >> >> not to >> >> denigrate Lucene.Net, it is one of the best pieces of software I have >> >> used. >> >> >> >> So, this email should be considered an introduction and a request >> to be >> >> allowed to get involved. I have never worked on an Open Source >> project >> >> before so I'll need some guidance but I am willing to learn. I do >> have >> a >> >> couple of questions to start with: >> >> >> >> - Is there a roadmap for the product? Is there a roadmap for Lucene >> that >> >> we >> >> will try and follow? >> >> - Is there a preferred version of the .NET Framework that it is >> >> planned to >> >> support? >> >> >> >> Enough for now, just wanted to introduce myself and get involved. >> >> >> >> Cheers, >> >> Ciaran >> >> >> >> >> > >> >> >
