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 <thowar...@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 <geobmx...@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-...@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 <geobmx...@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-...@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:lombardena...@gmail.com] >>> Sent: Thursday, 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 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:geobmx...@hotmail.com] >>>> Sent: Wednesday, December 28, 2011 8:28 PM >>>> To: lucene-net-...@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: >>>> digyd...@gmail.com > To: lucene-net-...@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.ch...@gmail.com] > Sent: Wednesday, >>>> December 28, 2011 9:20 PM > To: >>>> lucene-net-...@lucene.apache.org > Cc: >>>> lucene-net-u...@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: mitiag...@gmail.com > > > To: >>>> lucene-net-u...@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 >>>
