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 Pure [was 'Lucene.Net project involvement']
Date Tue, 03 Apr 2007 19:45:00 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message