You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Ciaran Roarty <ci...@gmail.com> on 2007/04/02 12:44:19 UTC
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.
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.
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.
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.
Does that sound right? Any builds on this? Any problems with the approach?
Thanks in advance,
Ciaran Roarty
RE: Lucene.NET Pure [was 'Lucene.Net project involvement']
Posted by mi...@justanswer.com.
FYI: I've been using 2.0.0.3 on .NET 2.0 for months under heavy usage
without any problems.
-----Original Message-----
From: George Aroush [mailto:george@aroush.net]
Sent: Wednesday, April 04, 2007 6:11 PM
To: lucene-net-dev@incubator.apache.org
Subject: RE: Lucene.NET Pure [was 'Lucene.Net project involvement']
Hi Max,
To answer your questions:
1) I do expect to release 2.1 as an early alpha over this coming weekend.
2) Yes. 2.1 will be targeting .NET 2.0, (not my alpha release, but the
final release.)
3) This depends. If the port introduces new and unnecessary exceptions,
yes, they must be removed (whenever possible.) Valid exception use in the
Java version should not be removed from the C# version without close
examination since doing so can alter the flow of the code.
4) Yes, my preference is we hold off such work till we are in par with
Java's SVN. This said, if there are enough people actually working on the
code, then I don't see why we can't do this in parallel.
I hope this helps, since I see it as the road map too. As a community, we
can vote on this. I believe everyone would agree that till when we have
released 2.1 as final (item #2 above) -- with a good community involvement
-- there is not much value discussing #3 and #4.
Regards,
-- George
> -----Original Message-----
> From: Max Metral [mailto:max@artsalliancelabs.com]
> Sent: Tuesday, April 03, 2007 8:54 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: RE: Lucene.NET Pure [was 'Lucene.Net project involvement']
>
> Can I get some clarification on what you're recommending George?
>
> * Lucene.Net 2.1 will be out in the next x weeks (1?)
> * Lucene.Net 2.1 will be .Net 2.0 specific, or partly?
> * Lucene.Net 2.1 will remove the biggest exception offenders?
> * You recommending waiting on further .Net 2.0 optimization until...?
>
> (I'm thinking the answer to the last is "until we're up to Java SVN,"
> in which case perhaps some of us pro-2.0-ers could help with that.)
>
> --Max
>
> -----Original Message-----
> From: George Aroush [mailto:george@aroush.net]
> Sent: Tuesday, April 03, 2007 6:56 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: RE: Lucene.NET Pure [was 'Lucene.Net project involvement']
>
> Erik: I agree with your suggestion and I don't think any one is
> stiffing any innovation. I'm questioning the value and if this is the
> right time to do this. At this point, it makes better sense to use
> our cycles on brining the code base in par with Java's code base.
>
> Ciaran: If you want to give this a try, go ahead. You can start now
> with the existing Lucene.Net 2.0 or wait a bit more for 2.1 release
> and report back about your effort. IMHO, I believe, while you do this
> change, the existing public interfaces of Lucene.Net will end up
> changing too and those changes will have ripple effect all over the
> code base; but I like to be proven otherwise and your experiment might
> put us on a new track. So go for it!
>
> -- George
>
> > -----Original Message-----
> > From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> > Sent: Tuesday, April 03, 2007 4:58 PM
> > To: lucene-net-dev@incubator.apache.org
> > Subject: Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
> >
> > The best way to move forward from here is with actual code that
> > demonstrates the benefits. What I don't like seeing is the
> impression
> > that innovation is being stifled. If folks have great ideas, let's
> > see 'em. While George is the initiator of Lucene.Net, the
> community
> > owns it. I'm happy to see several folks speak up here about their
> > interest in personally helping this project along. This is exactly
> > what it needs. The more the merrier!
> >
> > Having a branch that is innovating with more hand-made C#
> sounds great
> > to me. The comparisons and contrasts between the two approaches
> > becomes more concrete, allowing objective decisions based on some
> > benchmarking and other factors.
> >
> > Erik
> >
> >
> >
> > On Apr 3, 2007, at 4:09 PM, Michael Garski wrote:
> >
> > > 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 <ge...@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 <ge...@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
> > >>> > > >
> > >>> > >
> > >>> > >
> > >>> >
> > >>>
> > >>>
> > >>
> >
>
RE: Lucene.NET Pure [was 'Lucene.Net project involvement']
Posted by George Aroush <ge...@aroush.net>.
Hi Max,
To answer your questions:
1) I do expect to release 2.1 as an early alpha over this coming weekend.
2) Yes. 2.1 will be targeting .NET 2.0, (not my alpha release, but the
final release.)
3) This depends. If the port introduces new and unnecessary exceptions,
yes, they must be removed (whenever possible.) Valid exception use in the
Java version should not be removed from the C# version without close
examination since doing so can alter the flow of the code.
4) Yes, my preference is we hold off such work till we are in par with
Java's SVN. This said, if there are enough people actually working on the
code, then I don't see why we can't do this in parallel.
I hope this helps, since I see it as the road map too. As a community, we
can vote on this. I believe everyone would agree that till when we have
released 2.1 as final (item #2 above) -- with a good community involvement
-- there is not much value discussing #3 and #4.
Regards,
-- George
> -----Original Message-----
> From: Max Metral [mailto:max@artsalliancelabs.com]
> Sent: Tuesday, April 03, 2007 8:54 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: RE: Lucene.NET Pure [was 'Lucene.Net project involvement']
>
> Can I get some clarification on what you're recommending George?
>
> * Lucene.Net 2.1 will be out in the next x weeks (1?)
> * Lucene.Net 2.1 will be .Net 2.0 specific, or partly?
> * Lucene.Net 2.1 will remove the biggest exception offenders?
> * You recommending waiting on further .Net 2.0 optimization until...?
>
> (I'm thinking the answer to the last is "until we're up to
> Java SVN," in which case perhaps some of us pro-2.0-ers could
> help with that.)
>
> --Max
>
> -----Original Message-----
> From: George Aroush [mailto:george@aroush.net]
> Sent: Tuesday, April 03, 2007 6:56 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: RE: Lucene.NET Pure [was 'Lucene.Net project involvement']
>
> Erik: I agree with your suggestion and I don't think any one
> is stiffing any innovation. I'm questioning the value and if
> this is the right time to do this. At this point, it makes
> better sense to use our cycles on brining the code base in
> par with Java's code base.
>
> Ciaran: If you want to give this a try, go ahead. You can
> start now with the existing Lucene.Net 2.0 or wait a bit more
> for 2.1 release and report back about your effort. IMHO, I
> believe, while you do this change, the existing public
> interfaces of Lucene.Net will end up changing too and those
> changes will have ripple effect all over the code base; but I
> like to be proven otherwise and your experiment might put us
> on a new track. So go for it!
>
> -- George
>
> > -----Original Message-----
> > From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> > Sent: Tuesday, April 03, 2007 4:58 PM
> > To: lucene-net-dev@incubator.apache.org
> > Subject: Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
> >
> > The best way to move forward from here is with actual code that
> > demonstrates the benefits. What I don't like seeing is the
> impression
> > that innovation is being stifled. If folks have great ideas, let's
> > see 'em. While George is the initiator of Lucene.Net, the
> community
> > owns it. I'm happy to see several folks speak up here about their
> > interest in personally helping this project along. This is exactly
> > what it needs. The more the merrier!
> >
> > Having a branch that is innovating with more hand-made C#
> sounds great
> > to me. The comparisons and contrasts between the two approaches
> > becomes more concrete, allowing objective decisions based on some
> > benchmarking and other factors.
> >
> > Erik
> >
> >
> >
> > On Apr 3, 2007, at 4:09 PM, Michael Garski wrote:
> >
> > > 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 <ge...@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 <ge...@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
> > >>> > > >
> > >>> > >
> > >>> > >
> > >>> >
> > >>>
> > >>>
> > >>
> >
>
RE: Lucene.NET Pure [was 'Lucene.Net project involvement']
Posted by Max Metral <ma...@artsalliancelabs.com>.
Can I get some clarification on what you're recommending George?
* Lucene.Net 2.1 will be out in the next x weeks (1?)
* Lucene.Net 2.1 will be .Net 2.0 specific, or partly?
* Lucene.Net 2.1 will remove the biggest exception offenders?
* You recommending waiting on further .Net 2.0 optimization until...?
(I'm thinking the answer to the last is "until we're up to Java SVN," in
which case perhaps some of us pro-2.0-ers could help with that.)
--Max
-----Original Message-----
From: George Aroush [mailto:george@aroush.net]
Sent: Tuesday, April 03, 2007 6:56 PM
To: lucene-net-dev@incubator.apache.org
Subject: RE: Lucene.NET Pure [was 'Lucene.Net project involvement']
Erik: I agree with your suggestion and I don't think any one is stiffing
any
innovation. I'm questioning the value and if this is the right time to
do
this. At this point, it makes better sense to use our cycles on brining
the
code base in par with Java's code base.
Ciaran: If you want to give this a try, go ahead. You can start now
with
the existing Lucene.Net 2.0 or wait a bit more for 2.1 release and
report
back about your effort. IMHO, I believe, while you do this change, the
existing public interfaces of Lucene.Net will end up changing too and
those
changes will have ripple effect all over the code base; but I like to be
proven otherwise and your experiment might put us on a new track. So go
for
it!
-- George
> -----Original Message-----
> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> Sent: Tuesday, April 03, 2007 4:58 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
>
> The best way to move forward from here is with actual code
> that demonstrates the benefits. What I don't like seeing is
> the impression that innovation is being stifled. If folks
> have great ideas, let's see 'em. While George is the
> initiator of Lucene.Net, the community owns it. I'm happy to
> see several folks speak up here about their interest in
> personally helping this project along. This is exactly what
> it needs. The more the merrier!
>
> Having a branch that is innovating with more hand-made C#
> sounds great to me. The comparisons and contrasts between
> the two approaches becomes more concrete, allowing objective
> decisions based on some benchmarking and other factors.
>
> Erik
>
>
>
> On Apr 3, 2007, at 4:09 PM, Michael Garski wrote:
>
> > 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 <ge...@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 <ge...@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
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>>
> >>>
> >>
>
RE: Lucene.Net version to get
Posted by George Aroush <ge...@aroush.net>.
Hi James,
My original plan was to get an early alpha release over this past weekend,
but it didn't happen. I will see if I can make it over this coming weekend.
Regards,
-- George
> -----Original Message-----
> From: Shaw, James [mailto:James_Shaw@intuit.com]
> Sent: Thursday, April 12, 2007 5:51 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: RE: Lucene.Net version to get
>
> Thanks George for the info.
>
> Also When do you think an official build for .NET 2.0 is
> coming out (w/o all the warnings you have when you convert it
> to .NET 2.0 right now)?
>
> -----Original Message-----
> From: George Aroush [mailto:george@aroush.net]
> Sent: Tuesday, April 10, 2007 5:40 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: RE: Lucene.Net version to get
>
> Hi James,
>
> A while back, I re-packaged this release as build 4. It is
> currently staged
> here: http://people.apache.org/~aroush/Lucene.Net-2.0-004/
> and I'm still waiting for three +1 binding votes. So far I
> only got 1 +1 vote. I don't know why, but it seems to be
> taking a while. I just submitted another reminder to the
> PMC, lets hope it gets on their radar this time.
>
> Erik: if you can help, please do so.
>
> James: If you are currently using build 3, then 4 is 99% the
> same. And yes, 2.0 is backward compatible with 1.9.x on the
> index side of things.
> However,
> 2.0 has removed depreciated APIs.
>
> Regards,
>
> -- George Aroush
>
>
> > -----Original Message-----
> > From: Shaw, James [mailto:James_Shaw@intuit.com]
> > Sent: Saturday, April 07, 2007 9:03 PM
> > To: lucene-net-dev@incubator.apache.org
> > Subject: Lucene.Net version to get
> >
> > George and all,
> > I got the Lucene.Net 2.0 in
> >
> > Lucene.Net.2.0-003-26Feb27.src.zip
> >
> > that was posted in
> >
> > http://incubator.apache.org/lucene.net/download/
> >
> > but know that it had been pulled for not following Apache voting
> > process.
> >
> > Will the same build will re-appear as a stable release soon?
> > I read from the mailing list it would be Lucene.Net.2.0-004
> that gets
> > posted rather than 003? I guess my main question is if our company
> > wants to use stable (released to public) build of
> Lucene.Net 2.0, what
> > build should we get, and when should we expect it to be available?
> >
> > Also is Lucene 2.0 backwards compatible with Lucene 1.9.x,
> i.e., can
> > 2.0 read index created with 1.9.x?
> >
> > Thanks in advance for your answers.
> >
>
RE: Lucene.Net version to get
Posted by "Shaw, James" <Ja...@intuit.com>.
Thanks George for the info.
Also When do you think an official build for .NET 2.0 is coming out (w/o
all the warnings you have when you convert it to .NET 2.0 right now)?
-----Original Message-----
From: George Aroush [mailto:george@aroush.net]
Sent: Tuesday, April 10, 2007 5:40 PM
To: lucene-net-dev@incubator.apache.org
Subject: RE: Lucene.Net version to get
Hi James,
A while back, I re-packaged this release as build 4. It is currently
staged
here: http://people.apache.org/~aroush/Lucene.Net-2.0-004/ and I'm still
waiting for three +1 binding votes. So far I only got 1 +1 vote. I
don't
know why, but it seems to be taking a while. I just submitted another
reminder to the PMC, lets hope it gets on their radar this time.
Erik: if you can help, please do so.
James: If you are currently using build 3, then 4 is 99% the same. And
yes,
2.0 is backward compatible with 1.9.x on the index side of things.
However,
2.0 has removed depreciated APIs.
Regards,
-- George Aroush
> -----Original Message-----
> From: Shaw, James [mailto:James_Shaw@intuit.com]
> Sent: Saturday, April 07, 2007 9:03 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: Lucene.Net version to get
>
> George and all,
> I got the Lucene.Net 2.0 in
>
> Lucene.Net.2.0-003-26Feb27.src.zip
>
> that was posted in
>
> http://incubator.apache.org/lucene.net/download/
>
> but know that it had been pulled for not following Apache
> voting process.
>
> Will the same build will re-appear as a stable release soon?
> I read from the mailing list it would be Lucene.Net.2.0-004
> that gets posted rather than 003? I guess my main question
> is if our company wants to use stable (released to public)
> build of Lucene.Net 2.0, what build should we get, and when
> should we expect it to be available?
>
> Also is Lucene 2.0 backwards compatible with Lucene 1.9.x,
> i.e., can 2.0 read index created with 1.9.x?
>
> Thanks in advance for your answers.
>
RE: Lucene.Net version to get
Posted by George Aroush <ge...@aroush.net>.
Hi James,
A while back, I re-packaged this release as build 4. It is currently staged
here: http://people.apache.org/~aroush/Lucene.Net-2.0-004/ and I'm still
waiting for three +1 binding votes. So far I only got 1 +1 vote. I don't
know why, but it seems to be taking a while. I just submitted another
reminder to the PMC, lets hope it gets on their radar this time.
Erik: if you can help, please do so.
James: If you are currently using build 3, then 4 is 99% the same. And yes,
2.0 is backward compatible with 1.9.x on the index side of things. However,
2.0 has removed depreciated APIs.
Regards,
-- George Aroush
> -----Original Message-----
> From: Shaw, James [mailto:James_Shaw@intuit.com]
> Sent: Saturday, April 07, 2007 9:03 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: Lucene.Net version to get
>
> George and all,
> I got the Lucene.Net 2.0 in
>
> Lucene.Net.2.0-003-26Feb27.src.zip
>
> that was posted in
>
> http://incubator.apache.org/lucene.net/download/
>
> but know that it had been pulled for not following Apache
> voting process.
>
> Will the same build will re-appear as a stable release soon?
> I read from the mailing list it would be Lucene.Net.2.0-004
> that gets posted rather than 003? I guess my main question
> is if our company wants to use stable (released to public)
> build of Lucene.Net 2.0, what build should we get, and when
> should we expect it to be available?
>
> Also is Lucene 2.0 backwards compatible with Lucene 1.9.x,
> i.e., can 2.0 read index created with 1.9.x?
>
> Thanks in advance for your answers.
>
Lucene.Net version to get
Posted by "Shaw, James" <Ja...@intuit.com>.
George and all,
I got the Lucene.Net 2.0 in
Lucene.Net.2.0-003-26Feb27.src.zip
that was posted in
http://incubator.apache.org/lucene.net/download/
but know that it had been pulled for not following Apache voting
process.
Will the same build will re-appear as a stable release soon? I read
from the mailing list it would be Lucene.Net.2.0-004 that gets posted
rather than 003? I guess my main question is if our company wants to
use stable (released to public) build of Lucene.Net 2.0, what build
should we get, and when should we expect it to be available?
Also is Lucene 2.0 backwards compatible with Lucene 1.9.x, i.e., can 2.0
read index created with 1.9.x?
Thanks in advance for your answers.
Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
Posted by Ciaran Roarty <ci...@gmail.com>.
Erik et al
I'll look into this over the weekend and workout how to get involved.
Have a good holiday weekend,
Ciaran
On 04/04/07, Erik Hatcher <er...@ehatchersolutions.com> wrote:
>
> Ciaran,
>
> The first step is to contribute some code as a patch (or full code
> dump) to an issue in our issue tracker.
>
> Here's a good overview of the roles we use on Apache projects:
>
> <http://apache.org/foundation/how-it-works.html#roles>
>
> "developer" is the next step up, and when that role has solidified in
> the community "committer" is considered.
>
> Erik
>
>
> On Apr 4, 2007, at 4:28 AM, Ciaran Roarty wrote:
>
> > George
> >
> > I think this would be best done on Lucene.Net 2.1 as this will
> > allow us to
> > see the impact of fixes to the 2.1 codebase on the branched code.
> >
> > Now, how do I go about getting a branch?
> >
> > Ciaran
> >
> >
> > On 03/04/07, George Aroush <ge...@aroush.net> wrote:
> >>
> >> Erik: I agree with your suggestion and I don't think any one is
> >> stiffing
> >> any
> >> innovation. I'm questioning the value and if this is the right
> >> time to do
> >> this. At this point, it makes better sense to use our cycles on
> >> brining
> >> the
> >> code base in par with Java's code base.
> >>
> >> Ciaran: If you want to give this a try, go ahead. You can start
> >> now with
> >> the existing Lucene.Net 2.0 or wait a bit more for 2.1 release and
> >> report
> >> back about your effort. IMHO, I believe, while you do this
> >> change, the
> >> existing public interfaces of Lucene.Net will end up changing too and
> >> those
> >> changes will have ripple effect all over the code base; but I like
> >> to be
> >> proven otherwise and your experiment might put us on a new track.
> >> So go
> >> for
> >> it!
> >>
> >> -- George
> >>
> >> > -----Original Message-----
> >> > From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> >> > Sent: Tuesday, April 03, 2007 4:58 PM
> >> > To: lucene-net-dev@incubator.apache.org
> >> > Subject: Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
> >> >
> >> > The best way to move forward from here is with actual code
> >> > that demonstrates the benefits. What I don't like seeing is
> >> > the impression that innovation is being stifled. If folks
> >> > have great ideas, let's see 'em. While George is the
> >> > initiator of Lucene.Net, the community owns it. I'm happy to
> >> > see several folks speak up here about their interest in
> >> > personally helping this project along. This is exactly what
> >> > it needs. The more the merrier!
> >> >
> >> > Having a branch that is innovating with more hand-made C#
> >> > sounds great to me. The comparisons and contrasts between
> >> > the two approaches becomes more concrete, allowing objective
> >> > decisions based on some benchmarking and other factors.
> >> >
> >> > Erik
> >> >
> >> >
> >> >
> >> > On Apr 3, 2007, at 4:09 PM, Michael Garski wrote:
> >> >
> >> > > 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 <ge...@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 <ge...@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
> >> > >>> > > >
> >> > >>> > >
> >> > >>> > >
> >> > >>> >
> >> > >>>
> >> > >>>
> >> > >>
> >> >
> >>
> >>
>
>
Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Ciaran,
The first step is to contribute some code as a patch (or full code
dump) to an issue in our issue tracker.
Here's a good overview of the roles we use on Apache projects:
<http://apache.org/foundation/how-it-works.html#roles>
"developer" is the next step up, and when that role has solidified in
the community "committer" is considered.
Erik
On Apr 4, 2007, at 4:28 AM, Ciaran Roarty wrote:
> George
>
> I think this would be best done on Lucene.Net 2.1 as this will
> allow us to
> see the impact of fixes to the 2.1 codebase on the branched code.
>
> Now, how do I go about getting a branch?
>
> Ciaran
>
>
> On 03/04/07, George Aroush <ge...@aroush.net> wrote:
>>
>> Erik: I agree with your suggestion and I don't think any one is
>> stiffing
>> any
>> innovation. I'm questioning the value and if this is the right
>> time to do
>> this. At this point, it makes better sense to use our cycles on
>> brining
>> the
>> code base in par with Java's code base.
>>
>> Ciaran: If you want to give this a try, go ahead. You can start
>> now with
>> the existing Lucene.Net 2.0 or wait a bit more for 2.1 release and
>> report
>> back about your effort. IMHO, I believe, while you do this
>> change, the
>> existing public interfaces of Lucene.Net will end up changing too and
>> those
>> changes will have ripple effect all over the code base; but I like
>> to be
>> proven otherwise and your experiment might put us on a new track.
>> So go
>> for
>> it!
>>
>> -- George
>>
>> > -----Original Message-----
>> > From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
>> > Sent: Tuesday, April 03, 2007 4:58 PM
>> > To: lucene-net-dev@incubator.apache.org
>> > Subject: Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
>> >
>> > The best way to move forward from here is with actual code
>> > that demonstrates the benefits. What I don't like seeing is
>> > the impression that innovation is being stifled. If folks
>> > have great ideas, let's see 'em. While George is the
>> > initiator of Lucene.Net, the community owns it. I'm happy to
>> > see several folks speak up here about their interest in
>> > personally helping this project along. This is exactly what
>> > it needs. The more the merrier!
>> >
>> > Having a branch that is innovating with more hand-made C#
>> > sounds great to me. The comparisons and contrasts between
>> > the two approaches becomes more concrete, allowing objective
>> > decisions based on some benchmarking and other factors.
>> >
>> > Erik
>> >
>> >
>> >
>> > On Apr 3, 2007, at 4:09 PM, Michael Garski wrote:
>> >
>> > > 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 <ge...@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 <ge...@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
>> > >>> > > >
>> > >>> > >
>> > >>> > >
>> > >>> >
>> > >>>
>> > >>>
>> > >>
>> >
>>
>>
Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Ciaran,
It would be a good idea to get an Apache CLA submitted and on file,
allowing you to come into the fold more deeply. It's available here:
<http://www.apache.org/licenses/#clas>
Erik
On Apr 4, 2007, at 4:28 AM, Ciaran Roarty wrote:
> George
>
> I think this would be best done on Lucene.Net 2.1 as this will
> allow us to
> see the impact of fixes to the 2.1 codebase on the branched code.
>
> Now, how do I go about getting a branch?
>
> Ciaran
>
>
> On 03/04/07, George Aroush <ge...@aroush.net> wrote:
>>
>> Erik: I agree with your suggestion and I don't think any one is
>> stiffing
>> any
>> innovation. I'm questioning the value and if this is the right
>> time to do
>> this. At this point, it makes better sense to use our cycles on
>> brining
>> the
>> code base in par with Java's code base.
>>
>> Ciaran: If you want to give this a try, go ahead. You can start
>> now with
>> the existing Lucene.Net 2.0 or wait a bit more for 2.1 release and
>> report
>> back about your effort. IMHO, I believe, while you do this
>> change, the
>> existing public interfaces of Lucene.Net will end up changing too and
>> those
>> changes will have ripple effect all over the code base; but I like
>> to be
>> proven otherwise and your experiment might put us on a new track.
>> So go
>> for
>> it!
>>
>> -- George
>>
>> > -----Original Message-----
>> > From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
>> > Sent: Tuesday, April 03, 2007 4:58 PM
>> > To: lucene-net-dev@incubator.apache.org
>> > Subject: Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
>> >
>> > The best way to move forward from here is with actual code
>> > that demonstrates the benefits. What I don't like seeing is
>> > the impression that innovation is being stifled. If folks
>> > have great ideas, let's see 'em. While George is the
>> > initiator of Lucene.Net, the community owns it. I'm happy to
>> > see several folks speak up here about their interest in
>> > personally helping this project along. This is exactly what
>> > it needs. The more the merrier!
>> >
>> > Having a branch that is innovating with more hand-made C#
>> > sounds great to me. The comparisons and contrasts between
>> > the two approaches becomes more concrete, allowing objective
>> > decisions based on some benchmarking and other factors.
>> >
>> > Erik
>> >
>> >
>> >
>> > On Apr 3, 2007, at 4:09 PM, Michael Garski wrote:
>> >
>> > > 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 <ge...@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 <ge...@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
>> > >>> > > >
>> > >>> > >
>> > >>> > >
>> > >>> >
>> > >>>
>> > >>>
>> > >>
>> >
>>
>>
Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
Posted by Ciaran Roarty <ci...@gmail.com>.
George
I think this would be best done on Lucene.Net 2.1 as this will allow us to
see the impact of fixes to the 2.1 codebase on the branched code.
Now, how do I go about getting a branch?
Ciaran
On 03/04/07, George Aroush <ge...@aroush.net> wrote:
>
> Erik: I agree with your suggestion and I don't think any one is stiffing
> any
> innovation. I'm questioning the value and if this is the right time to do
> this. At this point, it makes better sense to use our cycles on brining
> the
> code base in par with Java's code base.
>
> Ciaran: If you want to give this a try, go ahead. You can start now with
> the existing Lucene.Net 2.0 or wait a bit more for 2.1 release and report
> back about your effort. IMHO, I believe, while you do this change, the
> existing public interfaces of Lucene.Net will end up changing too and
> those
> changes will have ripple effect all over the code base; but I like to be
> proven otherwise and your experiment might put us on a new track. So go
> for
> it!
>
> -- George
>
> > -----Original Message-----
> > From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> > Sent: Tuesday, April 03, 2007 4:58 PM
> > To: lucene-net-dev@incubator.apache.org
> > Subject: Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
> >
> > The best way to move forward from here is with actual code
> > that demonstrates the benefits. What I don't like seeing is
> > the impression that innovation is being stifled. If folks
> > have great ideas, let's see 'em. While George is the
> > initiator of Lucene.Net, the community owns it. I'm happy to
> > see several folks speak up here about their interest in
> > personally helping this project along. This is exactly what
> > it needs. The more the merrier!
> >
> > Having a branch that is innovating with more hand-made C#
> > sounds great to me. The comparisons and contrasts between
> > the two approaches becomes more concrete, allowing objective
> > decisions based on some benchmarking and other factors.
> >
> > Erik
> >
> >
> >
> > On Apr 3, 2007, at 4:09 PM, Michael Garski wrote:
> >
> > > 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 <ge...@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 <ge...@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
> > >>> > > >
> > >>> > >
> > >>> > >
> > >>> >
> > >>>
> > >>>
> > >>
> >
>
>
RE: Lucene.NET Pure [was 'Lucene.Net project involvement']
Posted by George Aroush <ge...@aroush.net>.
Erik: I agree with your suggestion and I don't think any one is stiffing any
innovation. I'm questioning the value and if this is the right time to do
this. At this point, it makes better sense to use our cycles on brining the
code base in par with Java's code base.
Ciaran: If you want to give this a try, go ahead. You can start now with
the existing Lucene.Net 2.0 or wait a bit more for 2.1 release and report
back about your effort. IMHO, I believe, while you do this change, the
existing public interfaces of Lucene.Net will end up changing too and those
changes will have ripple effect all over the code base; but I like to be
proven otherwise and your experiment might put us on a new track. So go for
it!
-- George
> -----Original Message-----
> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> Sent: Tuesday, April 03, 2007 4:58 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
>
> The best way to move forward from here is with actual code
> that demonstrates the benefits. What I don't like seeing is
> the impression that innovation is being stifled. If folks
> have great ideas, let's see 'em. While George is the
> initiator of Lucene.Net, the community owns it. I'm happy to
> see several folks speak up here about their interest in
> personally helping this project along. This is exactly what
> it needs. The more the merrier!
>
> Having a branch that is innovating with more hand-made C#
> sounds great to me. The comparisons and contrasts between
> the two approaches becomes more concrete, allowing objective
> decisions based on some benchmarking and other factors.
>
> Erik
>
>
>
> On Apr 3, 2007, at 4:09 PM, Michael Garski wrote:
>
> > 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 <ge...@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 <ge...@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
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>>
> >>>
> >>
>
Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
The best way to move forward from here is with actual code that
demonstrates the benefits. What I don't like seeing is the
impression that innovation is being stifled. If folks have great
ideas, let's see 'em. While George is the initiator of Lucene.Net,
the community owns it. I'm happy to see several folks speak up here
about their interest in personally helping this project along. This
is exactly what it needs. The more the merrier!
Having a branch that is innovating with more hand-made C# sounds
great to me. The comparisons and contrasts between the two
approaches becomes more concrete, allowing objective decisions based
on some benchmarking and other factors.
Erik
On Apr 3, 2007, at 4:09 PM, Michael Garski wrote:
> 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 <ge...@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 <ge...@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
>>> > > >
>>> > >
>>> > >
>>> >
>>>
>>>
>>
Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
Posted by Michael Garski <mg...@mac.com>.
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 <ge...@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 <ge...@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
>> > > >
>> > >
>> > >
>> >
>>
>>
>
Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
Posted by Ciaran Roarty <ci...@gmail.com>.
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 <ge...@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 <ge...@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
> > > >
> > >
> > >
> >
>
>
RE: Lucene.NET Pure [was 'Lucene.Net project involvement']
Posted by George Aroush <ge...@aroush.net>.
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 <ge...@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
> > >
> >
> >
>
Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
Posted by Ciaran Roarty <ci...@gmail.com>.
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 <ge...@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
> >
>
>
RE: Lucene.NET Pure [was 'Lucene.Net project involvement']
Posted by George Aroush <ge...@aroush.net>.
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
>