lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ciaran Roarty" <ciaran.roa...@gmail.com>
Subject Re: Lucene.Net project involvement
Date Wed, 28 Mar 2007 08:22:01 GMT
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 <mitiaguinm@optusnet.com.au> 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 <mitiaguinm@optusnet.com.au> 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 <njedeh@yahoo.com> wrote:
> >> >
> >> >>
> >> >> I set up my lucene to a .net 2.0 framework, using VB and it works
> >> >> well in
> >> >> that environment.
> >> >>
> >> >> Anthony
> >> >>
> >> >> Ciaran Roarty <ciaran.roarty@gmail.com> 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
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message