Sean, I have a patch for TestIndexWriterLockRelease.TestDummy(), but I forgot to include it in the list (sorry). The patch is TestIndexWriterLockRelease.patch and is available here: https://issues.apache.org/jira/browse/LUCENENET-154 In the interest of clarity, here is the revised patch list: - PATCHES TO SVN HEAD FOR LUCENE.NET 2.3.1 - LUCENENET-135 SupportClass.patch LUCENENET-143 TestStressIndexing2.patch, FieldsReader.patch LUCENENET-145 DocumentsWriter.patch LUCENENET-146 SegmentTermPositionVector.patch LUCENENET-152 SegmentInfos.patch LUCENENET-154 TestIndexWriterLockRelease.patch LUCENENET-155 SetUp.patch Regarding the test failure in TestIndexWriter.TestMaxThreadPriority(): I can't replicate this error. If you currently have, or come up with, a patch for this issue that would be great. Either way, this issue should be logged in JIRA. If you don't have a JIRA account, you can get one here: http://issues.apache.org/jira/secure/Signup!default.jspa Thanks, Doug On Wed, Oct 8, 2008 at 10:19 AM, Sean Carpenter wrote: > Doug, > I was able to spend some time today looking at my test failures. They are: > TestIndexWriter.TestMaxThreadPriority() - fails resetting the thread > priority in the finally() clause with the exception: "Thread is dead; > priority cannot be accessed." I'm running on a dual-core machine - I > haven't investigated yet to see if this is the issue. > TestSpans.TestSpanNearOrdered0[2-5]() - as expected. > TestIndexWriterLockRelease.TestDummy() - this fails during TearDown because > the __test_dir variable is not null due to a previous execution of > _TestIndexWriterLockRelease. Each test runs successfully when I execute > them individually. I think adding a this.__test_dir = null; statement to > the end of the TearDown method will fix this issue - I believe it is due to > JUnit and NUnit differences that you alluded to in an earlier message. > > I ignored the TestHugeRamFile test based on your comments. > > Sean > > On Tue, Oct 7, 2008 at 1:43 PM, Max Metral > wrote: > > > Not to toss too much water on NAnt, but why not use MSBuild instead? > > That way you can use the existing core sln/project files, but still > > don't need VStudio. > > > > -----Original Message----- > > From: Doug Sale [mailto:dougsale@gmail.com] > > Sent: Tuesday, October 07, 2008 1:00 PM > > To: lucene-net-dev@incubator.apache.org > > Subject: Re: Current Status/Plans for Lucene.Net 2.3 > > > > Sean, > > > > AFAIK, no one is working on that. I think that would be useful - it > > would > > encourage development by people who don't want to or are not able to use > > Visual Studio. > > > > Regarding test failures, I expect > > TestStressIndexing.TestStressIndexAndSearching(), > > TestSpans.TestSpanNearOrdered0[2-5](), and > > TestHugeRamFile.TestHugeFile() to > > fail. > > > > Where does your experience diverge? > > > > BTW, I don't believe there is an issue with the latter test. When I > > reduce > > the size of the file by a factor of 2 the test succeeds on my machines. > > I > > believe it is merely an "eating all your memory and virtual memory" > > issue. > > > > As I mentioned, previously - I'm investigating the tests listed above, > > but > > welcome any and all assistance. > > > > Thanks. > > > > > > On Mon, Oct 6, 2008 at 10:21 AM, Sean Carpenter > > wrote: > > > > > I was able to apply all of the suggested patches and I currently get 7 > > test > > > failures. I haven't had a chance to dig into them yet, but one thing > > that > > > took me some time was getting everything set up to build and run the > > tests. > > > I was thinking of contributing a NAnt build file that would make it > > easier > > > for people to get set up and running. > > > Is there any interest in that (or is someone already working on it)? > > > > > > Thanks, > > > Sean > > > > > > On Fri, Oct 3, 2008 at 7:35 AM, Sean Carpenter > > >wrote: > > > > > > > Doug,Thanks for the update. I'll apply those patches this weekend > > and > > > see > > > > what I come up with. > > > > > > > > Sean > > > > > > > > > > > > On Thu, Oct 2, 2008 at 3:29 PM, Doug Sale > > wrote: > > > > > > > >> Sean, > > > >> > > > >> Currently, there are two people working on the 2.3.1 port - myself, > > and > > > >> DIGY. Neither of us are committers, but the understanding is that > > we > > > soon > > > >> will be. > > > >> > > > >> IMHO, there are 7 outstanding patches across 6 JIRA issues that > > should > > > be > > > >> applied to SVN HEAD: > > > >> LUCENENET-135 SupportClass.patch > > > >> LUCENENET-143 TestStressIndexing2.patch, FieldsReader.patch > > > >> LUCENENET-145 DocumentsWriter.patch > > > >> LUCENENET-146 SegmentTermPositionVector.patch > > > >> LUCENENET-152 SegmentInfos.patch > > > >> LUCENENET-155 SetUp.patch > > > >> > > > >> After applying said patches, there remain unit test failures in > > > >> TestStressIndexing.TestStressIndexAndSearching() (intermittent > > > exceptions) > > > >> and TestSpans.TestSpanNearOrdered0[2-4]() (2 search results' > > relevance > > > >> ranking are swapped). > > > >> > > > >> I am currently attempting to resolve these issues. Any and all > > > >> assistance, > > > >> however, is welcome. A first step would be to apply these patches > > to > > > the > > > >> SVN HEAD and verify that your test results match mine. > > > >> > > > >> Additionally, on most machines TestHugeRamFile.TestHugeFile() will > > fail > > > >> due > > > >> to a lack of physical memory (and might crash VS and/or your > > system). > > > >> This > > > >> can be alleviated by reducing the size requirement in the unit > > test. > > > >> > > > >> The current committers are responsible for reviewing these patches, > > > >> applying > > > >> them when worthy, and determining when the code is ready for > > release. > > > >> > > > >> Also - I have a local version of the code with the 2.3.2 changes > > ported, > > > >> ready-to-go, once the current batch of patches have been applied > > and the > > > >> remaining issues have been resolved. > > > >> > > > >> -Doug > > > >> > > > >> > > > >> On Thu, Oct 2, 2008 at 6:38 AM, Sean Carpenter > > > > >> >wrote: > > > >> > > > >> > I am curious as to the current state of the 2.3.1 port. These > > doesn't > > > >> seem > > > >> > to be much activity on the dev list or in the JIRA, and there are > > > >> several > > > >> > outstanding patches in the JIRA. When I checked out the code > > this > > > >> morning > > > >> > and ran the tests, I got a bunch of failures and an exception > > that > > > >> caused > > > >> > NUnit to close. > > > >> > I'd really like to see Lucene.Net keep up with the Java version > > as we > > > >> have > > > >> > a > > > >> > couple of existing projects and a few new ones at work that > > utilize > > > >> Lucene. > > > >> > What can I do to help? Is there a way to get the current > > outstanding > > > >> > patches applied to the trunk so that we have a common base to > > work > > > from? > > > >> > I'm happy to work on patches for the outstanding test failures, > > once > > > >> it's > > > >> > easier to determine which ones are still outstanding. > > > >> > > > > >> > Any thoughts? > > > >> > > > > >> > Thanks, > > > >> > Sean Carpenter > > > >> > > > > >> > > > > > > > > > > > > > >