lucene-lucene-net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Garski <mgar...@mac.com>
Subject Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
Date Tue, 03 Apr 2007 20:09:19 GMT
Hi Everyone,

I am going to have to side with George on this one.  Up to this point I 
believe he has been the sole contributor & committer to the Lucene.Net 
project, and has been porting over the code once the Java group released 
a version.  Attempting to exploit the advantages in the .NET framework 
and continuing to release Lucene.Net in that manner will require lots of 
repetitive work.  Once we can maintain the Lucene.Net trunk identical to 
the Java trunk (within a day or two), then we can safely start altering 
internal implementations to take full advantage of the .NET platform and 
not fall out of step with the API or functionality of Java Lucene.

Of those that are interested in development of Lucene, I highly suggest 
subscribing to the Java Developer mailing list to see what changes are 
being suggested and made.  Incorporating those changes manually on the 
.NET side in a relatively short period after they are committed on the 
Java side will take additional people.  I for one am interested in this 
as I have the luxury of being able to contribute during my normal work day.

While I do agree that everyone will benefit from changes that exploit 
the differences in the .NET framework, we'll need to start with a 
smaller, more reasonable goal.  Has anyone thought of how we can 
actually maintain a manual port that is reflective of the current Java 
trunk?  My first thought is that a changelog will need to be kept in 
each class file indicating which Java SVN version the file was last 
ported from.  Any other ideas on that?

Michael

Ciaran Roarty wrote:
> George
>
> Thanks for the clarification. I think that you miss a central point of 
> what
> I am trying to achieve and hopefully I will make this evident in my
> response.
>
> I understand that changing Lucene.Net - I hesitate to keep using the word
> 'pure' - into a .NET 2.0 specific library is a big change. However, I 
> cannot
> understand why you think changes in the internals of a class will 
> ripple all
> the way up a chain. Obviously, if the accessible interface changes 
> then we
> would break calling code but much of the 'guts' of the code is not
> accessible outside of the class.
>
> I understand your reticence to diverge effort but I regard this 
> exercise as
> a complementary task - it depends on a stable release of Lucene.Net; 
> it does
> not replace it. By attempting to create a .NET 2.0 library, the community
> can learn the lessons of how to take Lucene.Net to Lucene.Net.2.0. As you
> rightly point out, there will be difficulties in doing this per Lucene
> release but if we learn how to do it now then we can drive out those
> difficulties and understand where they occur.... if we do not do it 
> now then
> we will not know and, I suggest, we will not be able to do it in the 
> future
> without far more pain.
>
> Does anyone on the list have an opinion on this? If the community does 
> not
> think that there is any value in having a 'purer' Lucene.Net.2.0 then 
> that's
> fine; if this effort is not supported then I will let it go.
>
> Can you advise me of what is included in Lucene.Net 2.1 which is new? Is
> there a published roadmap for Lucene?
>
> Ciaran
>
> On 03/04/07, George Aroush <george@aroush.net> wrote:
>>
>> Hi Ciaran,
>>
>> Your goal is well understood; my pushback with it is in the approach you
>> are
>> proposing and the timing.
>>
>> The current port is not 'purur' in the sense that it doesn't take
>> advantage
>> of what .NET 2.0 framework has to offer (this is because JLCA only 
>> targets
>> .NET 1.1.)  Spinning off Lucene.Net 2.1 into another branch and 
>> making it
>> 'purur' will make life very difficult to keep up with any upcoming Java
>> Lucene releases because the code base will be so different (in the
>> Lucene.Net code base) to figure out what has changed in comparison with
>> the
>> Java version when porting 2.2 for example.  Not to mention, it will also
>> consume a good deal of our limited resources and to make the current 
>> code
>> 'purur' is no easy task.
>>
>> If you are not convince, please give it a try.  You will see one change,
>> in
>> one file, leading to several changes across several files (and keep in
>> mind
>> you also have all the "contrib" code too which must continue to work.)
>>
>> Before we undertake this task, which I consider a very challenging task,
>> I'm
>> suggesting that we first prove yourself.  The prove will be that we get
>> Lucene.Net 2.1 in a timely fashion, and that we can get the C# Lucene's
>> SVN
>> in par with the Java Lucene's SVN.  If and when we achieve this 
>> milestone,
>> then we can start porting changes from the Java land to the C# land on a
>> weekly basic, or even sooner, and have the time to make the existing
>> Lucene.Net code base 'purur'.
>>
>> In a nutshell, there are more important and urgent work we need to get
>> done
>> then start work on making the code 'purur'.
>>
>> Regards,
>>
>> -- George
>>
>> > -----Original Message-----
>> > From: Ciaran Roarty [mailto:ciaran.roarty@gmail.com]
>> > Sent: Tuesday, April 03, 2007 5:58 AM
>> > To: lucene-net-dev@incubator.apache.org
>> > Subject: Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
>> >
>> > 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 <george@aroush.net> wrote:
>> > >
>> > > Hi Ciaran,
>> > >
>> > > Please see my comments below.  Thanks.
>> > >
>> > > -- George Aroush
>> > >
>> > > > -----Original Message-----
>> > > > From: Ciaran Roarty [mailto:ciaran.roarty@gmail.com]
>> > > > Sent: Monday, April 02, 2007 6:44 AM
>> > > > To: lucene-net-dev@incubator.apache.org
>> > > > 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
>> > > >
>> > >
>> > >
>> >
>>
>>
>


Mime
View raw message