ntered over and
> > over so the number of porting strategy overrides to create should be
> limited
> > and reusable. Once you have that the only thing to maintain is a config
> file
> > that tells Sharpen how to handle the tricky parts.
> >
> > One other t
gt; > Date: Fri, 30 Dec 2011 14:10:16 +0000
> > > From: andy.p...@gmail.com
> > > To: lucene-net-...@lucene.apache.org
> > > Subject: Re: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g
> > >
> > > Thought I'd add my opinion as a user of Lucene.net...
>
000
> From: andy.p...@gmail.com
> To: lucene-net-...@lucene.apache.org
> Subject: Re: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g
>
> Thought I'd add my opinion as a user of Lucene.net...
>
> My company processes content from several feeds (mainly web but also social
>
e JVM is an inferior runtime to the CLR and the Java language
> > >> is like C#'s retarded cousin. I'll gladly write a new book on the new
> > >> API and publish it for free online, so people don't have to read
> > >> "Lucene in Action&qu
care less about keeping the API in line with java.
> I don't really care about the line by line - but others in the past have
> said they did. My energy isn't really behind keeping that in line but I'll
> help maintain it if that is what the community really wants. But
To make it clear - I want a .Net idiomatic API as the only API. I've got
experience with both kinds of APIs - strict transliterated from Java and
translated from Java to .Net. For me, the choice is pretty clear - the
latter has the advantage when it comes to long-term maintenance and support
from .
> at the same time, I realize we are a small community, and if we don't really
> agree with what we want to do, then we are SOL - I'm FLEXIBLE if others
> really want something or feel we should do something. ~P
>
> > Date: Thu, 29 Dec 2011 20:51:09 -0500
>> From
e: Thu, 29 Dec 2011 20:51:09 -0500
> From: mhern...@wickedsoftware.net
> To: lucene-net-...@lucene.apache.org
> Subject: Re: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g
>
> Might I suggest that we all approach this as a business owners, community
> builders, startup entrepreneurs i
changes required and publish the spec
> > >
> > > And to drive home the point I made in my first sentence: If had
> > > already accomplished those three agenda items, the time I just spent
> > > typing this email could have been spent working on Lucene.Net. We need
; > And to drive home the point I made in my first sentence: If had
> > already accomplished those three agenda items, the time I just spent
> > typing this email could have been spent working on Lucene.Net. We need
> > to get to that point if we want to maintain any kind of deve
ind of development
> velocity.
>
> Thanks,
> Troy
>
>
> On Thu, Dec 29, 2011 at 2:38 PM, Prescott Nasser
> wrote:
>> I dont think at the end of the day we want to make just cosmetic changes. We
>> also have the issue of same name different casing which needs
which needs to be fixed -
> but it's not clear how to manage that without some large adjustments to the
> API.
>
>
>
> Sent from my Windows Phone
>
> From: Troy Howard
> Sent: 12/29/2011 2:19 PM
> To: lucene-net-...@lucene.apach
Phone
From: Troy Howard
Sent: 12/29/2011 2:19 PM
To: lucene-net-...@lucene.apache.org
Subject: Re: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g
My vote goes to merging the two:
Apply the same concepts from 2.9.4g to 3.X development, using generics
where possible, Disposable vs Close, and exp
12/29/2011 1:16 PM
> To: lucene-net-...@lucene.apache.org
> Subject: RE: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g
>
> When I started that "g" branch, I had no intention to change the API, but at
> the end it resulted in a few changes
> like StopAnalyzer(List stopWords),
> Query.Extra
e.Net] Lucene.Net 3 onwards and 2.9.4g
When I started that "g" branch, I had no intention to change the API, but at
the end it resulted in a few changes
like StopAnalyzer(List stopWords),
Query.ExtractTerms(ICollection) etc.
But I think, a drop-in replacement will work for most of the Lucen
;t hurt to give it a once over
Sent from my Windows Phone
From: Digy
Sent: 12/29/2011 1:30 PM
To: lucene-net-...@lucene.apache.org
Subject: RE: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g
I forgot to mention, 2.9.4g implements IDisposable for many of the classes
lucene-net-...@lucene.apache.org
Subject: RE: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g
I don't see the g branch differing all that much from the line-by-line port.
All the g branch does is change some data types as generics, but line by
line the code the same once the generics are declared.
y, December 29, 2011 5:05 PM
To: lucene-net-...@lucene.apache.org
Subject: RE: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g
I don't see the g branch differing all that much from the line-by-line port.
All the g branch does is change some data types as generics, but line by
line the code the same
ache.org
> Subject: RE: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g
>
>
> Any reason we can't continue this g branch and make it more
> and more .net like? I was thinking about what we've expressed
> at goals - we want a line by line port - it's easy to
> mai
19 matches
Mail list logo