lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ciaran Roarty" <>
Subject Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
Date Tue, 03 Apr 2007 09:57:32 GMT

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,

On 03/04/07, George Aroush <> wrote:
> Hi Ciaran,
> Please see my comments below.  Thanks.
> -- George Aroush
> > -----Original Message-----
> > From: Ciaran Roarty []
> > Sent: Monday, April 02, 2007 6:44 AM
> > To:
> > 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
> >

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