Then you must have over looked this: >>> This is a port of src\Demo\* and src\Lucene.Net\*. I was hoping to also >>> include src\Test\* but it's not ready yet (I got tied up with family
I.e.: src\Test\* is not committed yet; it is still based on 2.4.0 so don't bother to look into it for now. -- George -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Tuesday, October 27, 2009 2:21 AM To: [email protected] Subject: Re: Apache Lucene.Net 2.9.0 build 001 "Alpha" is now committed > I don't see how / why you run into > this issue. I run into this issue when I tried to build test project (src/test). George Aroush wrote: > The files that you listed in #1, and #2, are depreciated. Here is the > complete list: > > \src\Lucene.Net\Index\DirectoryIndexReader.cs > \src\Lucene.Net\Index\MultiSegmentReader.cs > \src\Lucene.Net\Index\ReadOnlyMultiSegmentReader.cs > \src\Lucene.Net\Index\StoredFieldsWriterPerField.cs > \src\Lucene.Net\Index\StoredFieldWriterPerThread.cs > \src\Lucene.Net\Search\Spans\NearSpans.cs > \src\Lucene.Net\Search\Spans\PayloadSpans.cs > \src\Lucene.Net\Search\ExtendedFieldCacheImpl.cs > \src\Lucene.Net\Search\NonMatchingScorer.cs > \src\Lucene.Net\Search\RemoteCachingWrapperFilter.cs > \src\Lucene.Net\Search\RemoteSearchable.cs > > I need to remove them from 2.9.0 but for now, I tend to keep them around > till when I get the test code committed. I don't see how / why you run into > this issue. Those files are not part of VS build project, so they should > not have effected you (unless if you have your own build system that pulls > in every file, do you?). > > -- George > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Monday, October 26, 2009 3:47 PM > To: [email protected] > Subject: Re: Apache Lucene.Net 2.9.0 build 001 "Alpha" is now committed > > Thanks a lot. > > Found so far: > 1) search/Spans/PayloadSpans.cs - is not included in the project file > (Lucene.Net). In order to compile one has to change PayloadSpans from > interface to an abstract class (PayloadSpans : Spans, but Spans is > declared as abstract class). Or alternativly Spans has to be an > interface, but it will require many changes in other source code. Is > there particular reasons to have Spans as abstract class rather than > interface (I don't see any implementation code in Spans)? > > 2) search/RemoteCachingWrapperFilter.cs > search/RemoteSearchable.cs > > - are not included in the project Lucene.Net file. > --- > Andrei > > George Aroush wrote: > >> Fixed. Renamed "Payload" to "Payloads". Thanks for being the first to >> > try > >> this out. >> >> -- George >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> Sent: Monday, October 26, 2009 7:26 AM >> To: [email protected] >> Subject: Re: Apache Lucene.Net 2.9.0 build 001 "Alpha" is now committed >> >> Hi, >> >> Src does not compile out of the box: >> folder Payloads - does not exist, what does exists - folder Payload >> (without ending s) >> Please, rename search/payload -> search/payloads >> >> Andrei >> >> George Aroush wrote: >> >> >>> Hi Folks, >>> >>> >>> >>> If you are watching lucene-net-commits<AT>incubator.apache.org you will >>> noticed that I just committed Apache Lucene.Net 2.9.0 build 001 "Alpha". >>> This is a port of src\Demo\* and src\Lucene.Net\*. I was hoping to also >>> include src\Test\* but it's not ready yet (I got tied up with family >>> commitment over this weekend to wrap it up). However, it's very close >>> > and > >>> >>> >> I >> >> >>> expect to deliver it by next weekend. >>> >>> >>> >>> Before my delivery of 2.9.0 code base, I tagged 2.4.0, and updated few >>> >>> >> files >> >> >>> in it. I also generated MSDN style documentation for it. You can find >>> > it > >>> in tags\Lucene.Net_2_4_0\* >>> >>> >>> >>> As for 2.9.0, indexing and searching works but not necessarily bug free, >>> >>> >> so >> >> >>> feel free to give it a shot and report back with issues and fixes via >>> >>> >> JIRA. >> >> >>> As in the past, I flagged port issues with {{Aroush-2.9}} (as well as >>> Debug.Fail() to catch run-time port issues). The majority of those port >>> issues are either none-issues, or minor. However, for now, I like to >>> >>> >> leave >> >> >>> them in for sanity check until when I get the test code ported. >>> >>> >>> >>> Also, if you are following Apache Java Lucene, you will notice that there >>> >>> >> is >> >> >>> a major issue with 2.9.0 >>> >>> >> (https://issues.apache.org/jira/browse/LUCENE-1974) >> >> >>> This prompted the need to release of 2.9.1 which may happen next week or >>> >>> >> so. >> >> >>> This means, once 2.9.1 is release, we have to adopt it too -- the port of >>> 2.9.1 should be minor and I'm thinking to role it up into 2.9.0. E.g.: >>> switch over to 2.9.1 rather than release Apache Lucene.Net 2.9.0 followed >>> with Apache Lucene.Net 2.9.1. >>> >>> >>> >>> Finally, any further communication about port progress, I will confine >>> >>> >> them >> >> >>> to lucene-net-dev@ mailing list only and I ask that we all do the same >>> moving forward. This way, we don't pollute the mailing list (I always >>> >>> >> used >> >> >>> both mailing list because we were a small community, but we are past that >>> now). >>> >>> >>> >>> That's it for now. So take 2.9.0 for a spin, and report back! >>> >>> >>> >>> Thanks. >>> >>> >>> >>> -- George >>> >>> >>> >>> >>> >> >> > > > >
