lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George Aroush" <geo...@aroush.net>
Subject RE: Lucene.NET Pure [was 'Lucene.Net project involvement']
Date Thu, 05 Apr 2007 01:11:20 GMT
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 <george@aroush.net> wrote:
> > >>>
> > >>> Hi Ciaran,
> > >>>
> > >>> Your goal is well understood; my pushback with it is in the 
> > >>> approach you are proposing and the timing.
> > >>>
> > >>> The current port is not 'purur' in the sense that it 
> doesn't take 
> > >>> advantage of what .NET 2.0 framework has to offer (this 
> is because 
> > >>> JLCA only targets .NET 1.1.)  Spinning off Lucene.Net 2.1 into 
> > >>> another branch and making it 'purur' will make life 
> very difficult 
> > >>> to keep up with any upcoming Java Lucene releases 
> because the code 
> > >>> base will be so different (in the Lucene.Net code base) 
> to figure 
> > >>> out what has changed in comparison with the Java version when 
> > >>> porting 2.2 for example.  Not to mention, it will also 
> consume a 
> > >>> good deal of our limited resources and to make the current code 
> > >>> 'purur' is no easy task.
> > >>>
> > >>> If you are not convince, please give it a try.  You 
> will see one 
> > >>> change, in one file, leading to several changes across several 
> > >>> files (and keep in mind you also have all the "contrib" 
> code too 
> > >>> which must continue to
> > >>> work.)
> > >>>
> > >>> Before we undertake this task, which I consider a very 
> challenging 
> > >>> task, I'm suggesting that we first prove yourself.  The 
> prove will 
> > >>> be that we get Lucene.Net 2.1 in a timely fashion, and 
> that we can 
> > >>> get the C# Lucene's SVN in par with the Java Lucene's 
> SVN.  If and 
> > >>> when we achieve this milestone, then we can start 
> porting changes 
> > >>> from the Java land to the C# land on a weekly basic, or even 
> > >>> sooner, and have the time to make
> > the existing
> > >>> Lucene.Net code base 'purur'.
> > >>>
> > >>> In a nutshell, there are more important and urgent work 
> we need to 
> > >>> get done then start work on making the code 'purur'.
> > >>>
> > >>> Regards,
> > >>>
> > >>> -- George
> > >>>
> > >>> > -----Original Message-----
> > >>> > From: Ciaran Roarty [mailto:ciaran.roarty@gmail.com]
> > >>> > Sent: Tuesday, April 03, 2007 5:58 AM
> > >>> > To: lucene-net-dev@incubator.apache.org
> > >>> > Subject: Re: Lucene.NET Pure [was 'Lucene.Net project
> > >>> involvement']
> > >>> >
> > >>> > George
> > >>> >
> > >>> > Thanks for your comments. I don't want to reply to 
> all of them 
> > >>> > and make the email completely unreadable so I will 
> try to sum up 
> > >>> > my thoughts and see where we go from there.
> > >>> >
> > >>> > I think we have conflicting views of what a 'pure' 
> Lucene.Net is 
> > >>> > and I'd like to make my case more clearly as I cannot imagine

> > >>> > that you would have a problem with it.
> > >>> >
> > >>> > Lucene.Net will always be driven by Lucene as the community 
> > >>> > around Lucene is mature and developing at pace compared to 
> > >>> > Lucene.Net; this is not a criticism, it is a fact of life.
> > >>> > What I don't understand is how that development is 
> progressing - 
> > >>> > i.e. what features are being added, what features are being 
> > >>> > removed, if performance is being improved...... I presume you

> > >>> > have a far better understanding of those realities.
> > >>> >
> > >>> > Now, Lucene.Net is a fully functioning, very performant, 
> > >>> > extremely useful component / library / product. I cannot 
> > >>> > emphasise how important Lucene.Netwas in developing a viable 
> > >>> > search strategy for a project I was working on recently.
> > >>> > However, I wanted the library to be a .NET 2.0 
> library; not just 
> > >>> > compiled under .NET 2.0.... I have an aversion to ArrayLists,

> > >>> > for example, and I'd like them to be replaced by Generic 
> > >>> > Collections.
> > >>> >
> > >>> > So, to achieve these two aims: keeping up with Lucene 
> and making 
> > >>> > Lucene.Netmore .NET 2.0 specific, I think we have to 
> prove the 
> > >>> > process..... By that, I mean we need to take a Lucene.Net 
> > >>> > release - I suggest 2.1 - and branch the codebase.
> > >>> > What this allows us to do, is to revise the 
> Lucene.Net release 
> > >>> > without affecting Lucene.Net's ability to move forward with 
> > >>> > Lucene enhancements and improvements whilst - in a low risk 
> > >>> > environment - learn the lessons of making Lucene.Net 'purer.'
> > >>> >
> > >>> > Does that make sense?
> > >>> >
> > >>> > Basically, I am happy with the functionality in 
> Lucene.Net just 
> > >>> > now and I think it would be a good thing to have an 
> optimised, 
> > >>> > purer .NET 2.0 version of the library. I understand that the 
> > >>> > Lucene.Net / Lucene relationship should not be broken 
> as Lucene 
> > >>> > is clearly still developing and we, as a community, can gain 
> > >>> > from this continued development.
> > >>> > However, I think the community can also gain from the 
> > >>> > development of an optimised for .NET 2.0version of 
> the library.
> > >>> >
> > >>> > That's my thinking. It is what I am truly interested 
> in doing. I 
> > >>> > think the community would respond well to a version of 
> > >>> > Lucene.Net which is optimised for .NET 2.0 and I 
> think we will 
> > >>> > struggle to do that with Lucene.Net alone as it necessarily 
> > >>> > follows Lucene developments.
> > >>> >
> > >>> > Thanks for reading,
> > >>> > Ciaran
> > >>> >
> > >>> > On 03/04/07, George Aroush <george@aroush.net> wrote:
> > >>> > >
> > >>> > > Hi Ciaran,
> > >>> > >
> > >>> > > Please see my comments below.  Thanks.
> > >>> > >
> > >>> > > -- George Aroush
> > >>> > >
> > >>> > > > -----Original Message-----
> > >>> > > > From: Ciaran Roarty [mailto:ciaran.roarty@gmail.com]
> > >>> > > > Sent: Monday, April 02, 2007 6:44 AM
> > >>> > > > To: lucene-net-dev@incubator.apache.org
> > >>> > > > Subject: Lucene.NET Pure [was 'Lucene.Net project
> > >>> involvement']
> > >>> > > >
> > >>> > > > Hi
> > >>> > > >
> > >>> > > > I just want to check some facts and see if I have
> > picked up
> > >>> the
> > >>> > > > right emphasis from the majority of the posts.
> > >>> > > >
> > >>> > > > Firstly, Lucene.NET 2.1 is due to be released soon.
> > >>> > >
> > >>> > > Yes, Lucene.Net 2.1, a first cut release should be out by
> > >>> > end of this
> > >>> > > week or over the coming weekend.  Btw, it's "Lucene.Net"
> > >>> > and not "Lucene.NET"
> > >>> > >
> > >>> > > > Secondly, the port of Lucene to Lucene.NET is not
> > an automatic
> > >>> > > > process and George does post-migration work currently
to
> > >>> > bring the
> > >>> > > > JLCA work closer to the .NET world.
> > >>> > > >
> > >>> > > > Using the Lucene.NET effort, people on this list have
> > >>> > gone away and
> > >>> > > > made the port of Lucene into a purer .NET version.
> > >>> > > > These changes have, however, stayed internal to their
> > >>> > work and they
> > >>> > > > have not been backported.
> > >>> > >
> > >>> > > Are you sure about this?  I have not read anyone saying
> > >>> this.  What
> > >>> > > folks have said is that they eliminated unnecessary
> > >>> exceptions from
> > >>> > > the Lucene.Net code; exceptions that also exist in the Java
> > >>> version
> > >>> > > and were brought over to C# via the port.  There is a JIRA
> > >>> > issue about
> > >>> > > this and we had a long discussion about it on this mailing
> > >>> > list some
> > >>> > > time ago.  The folks on the Java mailing list knew about
it
> > >>> > and fixed
> > >>> > > it for 2.1 release.
> > >>> > >
> > >>> > > > When I asked the question about getting involved in
the
> > >>> > project and
> > >>> > > > making Lucene.NET 'purer' - in a .NET sense - then there
> > >>> > appeared to
> > >>> > > > be a real desire to get involved with that process.
It was
> > >>> also
> > >>> > > > noted that this would need to be a manual process; I
> > >>> > suggested that
> > >>> > > > the next major release - Lucene.NET 2.1 - should be
the
> > >>> basis for
> > >>> > > > this work.
> > >>> > > >
> > >>> > > > Therefore, I think we should branch the code at 2.1
and
> > >>> > work on that
> > >>> > > > branch.
> > >>> > > > In that way, we do not stop the progress of Lucene.NET
in
> > >>> > line with
> > >>> > > > Lucene but we do get to make some .NET optimisations.
> > >>> > >
> > >>> > > I disagree about branching off a new baseline.  Like
> > I said in a
> > >>> > > previous posting, the first thing we need to do is bring
up
> > >>> > Lucene.Net
> > >>> > > to be in part with the code base of what's in the Java
> > >>> > Lucene SVN with
> > >>> > > what's in the C# Lucene SVN.  Once we achieve this
> > important but
> > >>> > > difficult milestone, and most importantly we prove 
> that we can 
> > >>> > > maintain it, then we can start looking at the existing code
> > >>> > base and
> > >>> > > make the code .NET 'purer'.
> > >>> > >
> > >>> > > > Lastly, I believe that .NET 2.0 was the preferred
> > >>> > platform for this
> > >>> > > > work and that it would be ok to use .NET 2.0 specific
> > >>> > capabilities.
> > >>> > >
> > >>> > > Yes, the work on Lucene.Net 2.1 will be release .NET 2.0
> > >>> > specific; but
> > >>> > > again, our first goal must be that we get in par with Java's
> > >>> Lucene
> > >>> > > SVN before we diverge the code into more .NET.
> > >>> > >
> > >>> > > > Does that sound right? Any builds on this? Any problems
> > >>> with the
> > >>> > > > approach?
> > >>> > > >
> > >>> > > > Thanks in advance,
> > >>> > > > Ciaran Roarty
> > >>> > > >
> > >>> > >
> > >>> > >
> > >>> >
> > >>>
> > >>>
> > >>
> > 
> 


Mime
View raw message