lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rory Plaire <codekai...@gmail.com>
Subject Re: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g
Date Fri, 30 Dec 2011 01:13:30 GMT
The other option for people not wanting a line-by-line port is to just
stick with whichever the last version that had a line-by-line
transliteration done to it. This is done in a number of projects where new
versions break compatibility. 2.9.4 is certainly a nice release...

-r

On Thu, Dec 29, 2011 at 4:32 PM, Troy Howard <thoward37@gmail.com> wrote:

> Thinking about it, I should make myself more clear regarding why I
> brought up IKVM again, just so no one gets the wrong idea about my
> intentions there...
>
> I only mentioned it as a justification for dropping line-by-line
> compatibility and as an alternative for people who really care about
> that. As we discussed previously, IKVMed Lucene is not Lucene.Net in a
> lot of important material ways. We are already deviating significantly
> from Java Lucene even with the "mostly line by line" approach. Compare
> Lucene.Net 2.9.4 and IKVMed Java Lucene 2.9.4. They are very different
> user experiences on a lot of levels (licensing, packaging, data types
> used, etc).
>
> But it's a *reasonable alternative* when a high-degree of consistency
> with Java Lucene is important to the end user and by pointing to IKVM
> as our answer to those users, we are free to move forward without that
> concern.
>
> That means, supposing we move away from Java significantly, as a new
> end user looking to employ Lucene in their .NET product, they can
> choose between IKVM Lucene (identical API to Java, can use the latest
> Java build, performs well, may have some problems with licensing and
> packaging) and Lucene.Net (different API but hopefully one that is
> more palatable to .NET users so it'd be easy to learn, perfoms better
> than IKVM, but has a dev cycle that lags behind Java, possibly by a
> lot).
>
> Existing users who like who Lucene.Net as it is now, may feel
> alienated because they would be forced to choose between learning the
> new API and dealing with a slow dev cycle, or adapting to IKVM which
> could be very difficult or impossible for them. Either one would
> require a code change. But of course, we run this risk with any change
> we make to what we are doing. I think a greater risk is that the
> project lacks direction.
>
> Anyway, it's just one idea/talking point towards the end goal of
> getting the general topic off the table completely.
>
> Thanks,
> Troy
>
>
> On Thu, Dec 29, 2011 at 3:32 PM, Troy Howard <thoward37@gmail.com> wrote:
> > Apologies upfront: another long email.
> >
> > My most firm opinion on this topic is that, as a community, we spend
> > too much time on this discussion. We should just simply commit to one
> > or the other path, or both, or some middle ground, or just commit to
> > not discussing it anymore and go with "whatever code gets written and
> > works is what we use" and leave it up to the discretion of the coder
> > who is actually spending time improving the product. Obviously the
> > last option is the worst of them.
> >
> > My view of our current roadmap is/was:
> >
> > 1. We'd maintain basic line-by-line consistency through the 2.x
> > releases. But 3.X and beyond were open to changing the API
> > significantly. We are committed to changing the API and internal
> > implementations in order to improve performance and developer
> > experience on .NET, but haven't yet had made a plan for that (eg, no
> > spec for a new API).
> >
> > 2. We'd try to automate the porting process so that it was repeatable
> > and easy to keep up with (or at least easier) and maintain a
> > line-by-line port in a branch. That means the .NET version would
> > ultimately be a very different product than the line-by-line port and
> > we'd be creating two separate but related products but where possible,
> > share code between them. Patching the line-by-line product from Java
> > would be easier and faster than patching the .NET product and so they
> > may end up with different release schedules.
> >
> > It seems that effort on improving automation of the port has tapered
> > off. As anyone who has done any of the porting from commit patches
> > from Java knows, a good portion of that work can be automated with
> > find/replace but substantial portions and certain scenarios is the
> > current code definitely cannot be and probably will never be able to
> > be fully automated.
> >
> > While I have been advocating "doing both" and trying to find a
> > strategy that makes sense for that, another option is to just
> > officially drop any concern for line-by-line consistency with Java. A
> > justification for that is simple: IKVM provides this already. The
> > licensing allows use in commercial apps and it's performance is close
> > to the same, so, AFAIK it's a viable replacement for a line-by-line
> > version of Lucene.Net in just about any context as long as no one is
> > modifying IKVM itself. I don't think it's unreasonable to suggest to
> > people who want a line-by-line version to use IKVM instead of
> > Lucene.Net.
> >
> > So, if we use that perspective and say that the need for a .NET usable
> > line-by-line version of Lucene is already available via IKVM, why
> > would we bother handcoding another one? It makes more sense to focus
> > our valuable hand coding work on making something that *improves* upon
> > the .NET development experience. It may cause us to be slow to
> > release, but for good reason.
> >
> > So it seems to me we have the following primary agenda items to deal
> with:
> >
> > 1. Make an official decision regarding line-by-line porting, publish
> > it and document our reasoning, so that we can end the ambiguity and
> > circular discussions
> > 2. If line-by-line porting is still part of our plan after we
> > accomplish Agenda Item #1, resume work on improving automation of
> > porting, creating scripts/tools/etc and document the process
> > 3. If having a different API for .NET is still part of our plan after
> > we accomplish Agenda Item #1, spec those API changes and associated
> > internal 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
> > to get to that point if we want to maintain any kind of development
> > velocity.
> >
> > Thanks,
> > Troy
> >
> >
> > On Thu, Dec 29, 2011 at 2:38 PM, Prescott Nasser <geobmx540@hotmail.com>
> 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
> 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-dev@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 exposing *additional* APIs
> >> for generics (but leaving the existing old ones) to enable the
> >> underlying performance improvements the generics offer. Also, expose
> >> IEnumerable<T> implementations vs Java style enumerables/iterators.
> >>
> >> If we are only adding to the existing and making relatively minor
> >> changes to enable generics, updating/maintenance should be relatively
> >> easy and it won't break anyone's code.
> >>
> >> Thanks,
> >> Troy
> >>
> >>
> >> On Thu, Dec 29, 2011 at 2:08 PM, Prescott Nasser <geobmx540@hotmail.com>
> wrote:
> >>> I agree its a matter of taste. I'd vote continue with g and evolve it
> to where we want a .net version to be. What do others think?
> >>>
> >>> Sent from my Windows Phone
> >>> ________________________________
> >>> From: Digy
> >>> Sent: 12/29/2011 1:16 PM
> >>> To: lucene-net-dev@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<string> stopWords),
> >>> Query.ExtractTerms(ICollection<string>) etc.
> >>> But I think, a drop-in replacement will work for most of the Lucene.Net
> >>> users (Of course some contribs have been also modified accordingly)
> >>>
> >>> Changing arraylists/collections with generic counterparts,
> GetEnumerator's
> >>> with foreach, AnonymousClass's with
> >>> Func<> or Action<>'s and Fixing LUCENENET-172 are things most
people
> would
> >>> not notice.
> >>>
> >>> This "g" version includes also some other patches that were fixed for
> >>> .GE.(=>) Lucene3.1 (Which? I have to rework on my commits)
> >>>
> >>> So, there isn't much change in API, more changes for developers and
> more
> >>> stable code(At least I think so, since I use this "g" version in
> production
> >>> env. for months without any problem. For short, 2.9.4g is a superset of
> >>> 2.9.4 in bugfix level)
> >>>
> >>>
> >>> As a result, creating a new branch for .Net friendly Lucene.Net or
> >>> continuing on this branch is just a matter of taste.
> >>>
> >>> DIGY
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Scott Lombard [mailto:lombardenator@gmail.com]
> >>> Sent: Thursday, December 29, 2011 5:05 PM
> >>> To: lucene-net-dev@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.
> >>>
> >>> I don't see 2.9.4g being any closer to a .NET style version than 2.9.4.
> >>> While it does generics use for list style variable types the underlying
> >>> classes are still the same and all of the problems with 2.9.4 not
> being .NET
> >>> enough would be true in 2.9.4g.
> >>>
> >>> I would have to refer to Digy on if it changes how an end user
> interacts
> >>> with Lucene.NET.  If it does not affect how the end user interacts with
> >>> Lucene.NET then I think we should merge it into the Trunk and go from
> there
> >>> on 3.0.3.
> >>>
> >>>
> >>> Scott
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Prescott Nasser [mailto:geobmx540@hotmail.com]
> >>>> Sent: Wednesday, December 28, 2011 8:28 PM
> >>>> To: lucene-net-dev@lucene.apache.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
> >>>> maintain parity with java and easy to compare. We also want a
> >>>> more .NET version - the g branch gets this started - although
> >>>> it's not as .Net as people want (I think).
> >>>>
> >>>>
> >>>>
> >>>> What if we used the g branch as our .Net version and
> >>>> continued to make it more .Net like? and kept the trunk as
> >>>> the line by line? The G branch seems like a good start to the
> >>>> more .Net version anyway - we might as well build off of that?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ---------------------------------------- > From:
> >>>> digydigy@gmail.com > To: lucene-net-dev@lucene.apache.org >
> >>>> Date: Thu, 29 Dec 2011 02:45:23 +0200 > Subject: RE:
> >>>> [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g > > > but I
> >>>> guess the future of 2.9.4g depends on the extent that it is
> >>>> becoming > more .NET like > > My intention while I was
> >>>> creating that branch was just to make 2.9.4 a > little bit
> >>>> more .Net like(+ maybe some performance). > I used many codes
> >>>> from 3.0.3 Java. So it is somewhere between 2.9.4 & 3.0.3 >
> >>>> But I didn't think it as a separate branch to evolve on its
> >>>> own path. It > is(or I think it is) the final version of 2.9
> >>>> > > DIGY > > -----Original Message----- > From: Christopher
> >>>> Currens [mailto:currens.chris@gmail.com] > Sent: Wednesday,
> >>>> December 28, 2011 9:20 PM > To:
> >>>> lucene-net-dev@lucene.apache.org > Cc:
> >>>> lucene-net-user@lucene.apache.org > Subject: Re: [Lucene.Net]
> >>>> Lucene.Net 3 onwards and 2.9.4g > > One of the benefits of
> >>>> moving forward with the conversion of the Java > Lucene, is
> >>>> that they're using more recent versions of Java that support
> >>>> > things like generics and enums, so the direct port is
> >>>> getting more and more > like .NET, though not in all respects
> >>>> of course. I'm of the mind, though, > that one of the larger
> >>>> annoyances, Iterables, should be converted to > Enumerables
> >>>> in the direct port. It makes it a pain to use it in .NET >
> >>>> without it inheriting from IEnumerable, since it can't be
> >>>> used in a foreach > loop or with linq. Also, since the direct
> >>>> port isn't perfect anyway, it > seems a port of the IDEA of
> >>>> iterating would be more in the spirit of what > we're trying
> >>>> to accomplish, since the code would pretty much be the same,
> >>>> > just with different method names. > > I sort of got off
> >>>> topic there for a second, but I guess the future of > 2.9.4g
> >>>> depends on the extent that it is becoming more .NET like. >
> >>>> Obviously, while java is starting to use similar constructs
> >>>> that we have > in .NET, it will never be perfect. Admittedly,
> >>>> I haven't looked at 2.9.4g > in a little while, so I'm not
> >>>> sure how much it now differs from 3.x, since > there's a
> >>>> relatively large change there already. > > Thanks, >
> >>>> Christopher > > On Thu, Dec 22, 2011 at 9:13 PM, Prescott
> >>>> Nasser > wrote: > > > > > That's a great question
- I know a
> >>>> lot of people like the generics, and I > > don't really want
> >>>> it to disappear. I'd like to keep it in parity with the > >
> >>>> trunk. But I know we also have a goal of making Lucene.Net
> >>>> more .Net like > > (further than 2.9.4g), and I don't know
> >>>> how that fits in. We are a pretty > > small community and I
> >>>> know everyone has some pretty busy schedules so it > > takes
> >>>> us considerable time to make big progress. Trying to keep
> >>>> three > > different code bases probably isn't the right way
> >>>> to go. > > > > > > > > > Date: Fri, 23 Dec
2011 13:02:03
> >>>> +1100 > > > From: mitiaguin@gmail.com > > > To:
> >>>> lucene-net-user@lucene.apache.org > > > Subject: [Lucene.Net]
> >>>> Lucene.Net 3 onwards and 2.9.4g > > > > > > I was
browsing
> >>>> "Roadmap" emails from November in Lucene developer list. > >
> >>>> It > > > remains unclear in what state Lucene 3 porting is
,
> >>>> but my question more > > > about 2.9.4g . > > > Is
it kind of
> >>>> experimental dead end variation of 2.9.4 with generics ? > Am
> >>>> > > > I right in classifying it as more .Net like 2.9.4 which
> >>>> is unrelated to > > > roadmap Lucene 3 porting effort. >
>
> >>>> ----- > > Checked by AVG - www.avg.com > Version: 2012.0.1901
> >>>> / Virus Database: 2109/4708 - Release Date: 12/28/11 >
> >>>>
> >>>
> >>> -----
> >>>
> >>> Checked by AVG - www.avg.com
> >>> Version: 2012.0.1901 / Virus Database: 2109/4710 - Release Date:
> 12/29/11
> >>>
>

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