I'm about and happy to update when you are ready. I think the build should start working for 203 if you add the nunit-console nuget package. At least work in the sense of the build will start. I'm still chasing those build time bugbears I haven't been able to slay yet.
As for getting to nuget.org -- who has the key? I've never had access to it so I'm not sure we can update what is out there. On Fri, Mar 24, 2017 at 09:10 Shad Storhaug <[email protected]> wrote: > Wyatt, Prescott, Itamar, anybody? We've almost got all of the tests > passing on #203 and would like to merge to master and release it with the > new pre-release label "beta2". > > If there is nobody available to get the build running after merging, could > someone give me access to TeamCity to work on it? > > Thanks, > Shad Storhaug (NightOwl888) > > From: Shad Storhaug > Sent: Tuesday, March 21, 2017 5:25 AM > To: '[email protected]' > Subject: API Work/Stabilization Update > > I am getting very close to getting #203 merged. I wouldn't go so far as to > say that the API is finished, but the most significant of the breaking API > changes are now behind us. > > BUILD/VERSIONING > > I just wanted to be sure there is someone available to help get the build > working after the merge. I think it would be appropriate to change the > pre-release label from "beta" to "beta2" (without resetting the build > number, since that is actually what NuGet uses). This would be primarily > because of a major breaking API change, but also to indicate another > advancement toward release. > > We should probably also get this onto NuGet as soon as possible to > (hopefully) make it easier to recruit help to stabilize and create some > integration packages for popular Microsoft frameworks. > > KNOWN ISSUES > > > 1. The QueryParser.Flexible custom localized message functionality > is currently not implemented for .NET core, so those tests are now failing. > > 2. The implementation of Lucene.Net.Expressions currently reads data > from the configuration file. This is not how modern libraries are supposed > to be built - instead we want any configuration to be pushed in from the > application that uses Lucene.Net. Reading from the configuration file > directly means no opportunity to use dependency injection. There is also a > namespace Support/Configuration that can and should be removed after the > implementation is refactored to be DI-friendly (see > http://blog.ploeh.dk/2014/05/19/di-friendly-framework/). I haven't yet > worked out how the implementation was done in .NET - in Java, the defaults > were read from an embedded resource file and could be overridden by passing > in a ClassLoader (similar to .NET's Assembly class) - if anyone has any > information on how the "auto generated" C# code was generated, please share. > > 3. The Collation functionality in Analysis.Common doesn't work with > icu-dotnet, and has been excluded from compilation using the constant > FEATURE_COLLATION. I am now convinced after reading the docs that it would > be better to port the similar functionality from Analysis.ICU because it > was designed to work with icu4j and is therefore more likely to work with > icu-dotnet. > > 4. The Highlighter PostingsHighlight and VectorHighlight > functionality relies on icu-dotnet, which doesn't have a close match for > the BreakIterator in the JRE, so there are likely some big differences in > the functionality. Several hacks were put in to make the tests pass, but > these are not likely to fix all of the issues in the wild. > > 5. There are several namespaces in Lucene.Net.Core and > Lucene.Net.Codecs that have broken documentation comments. > > 6. There are some concurrency and performance issues (as pointed out > by Vincent Van Den Burghe): > http://git.net/ml/general/2017-02/msg00168.html > > 7. We have around 2 dozen tests that fail during randomization > (averaging about 17 broken per run), and 8 tests that fail all/most of the > time. > > RESOLVED ISSUES (in addition to API refactoring) > > > 1. Finished implementing the randomization of Codecs, Culture, Time > Zone, and InfoStream in the TestFramework. > > 2. Added factories for Codec, DocValuesFormat, and PostingsFormat so > custom implementations can be provided via dependency injection instead of > using the Java-ish NamedSPILoader class. The name must now be provided by > an attribute (or by class naming convention) rather than via constructor, > so it can be read without creating an instance of the class. > > 3. Fixed several of the codecs in Lucene.Net.Codecs that were still > not functioning (and not being tested because of the unfinished RandomCodec > class and test mocks). > > 4. Reviewed all catch blocks in Lucene.Net.Core to ensure the right > type of exceptions are being caught and the right type re-thrown. > > 5. Fixed culture-sensitive comparison and sort order issues when > using strings in Lucene.Net.Core and Lucene.Net.Codecs. > > 6. Merged similar functionality in Support into the same class and > deleted several unused Support classes. > > 7. Made the API CLS compliant, so it now works with all .NET > languages. > > > Shad Storhaug (NightOwl888) >
