Mailing-List: contact dev-help@lucenenet.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucenenet.apache.org
From: Shad Storhaug <shad@shadstorhaug.com>
To: "dev@lucenenet.apache.org" <dev@lucenenet.apache.org>
Subject: RE: API Work/Stabilization Update
Thread-Topic: API Work/Stabilization Update
Thread-Index: AdKhvOvcIXmvWGKrQiiamlKrhD1bLQC4kDvA
Date: Fri, 24 Mar 2017 13:10:50 +0000
Message-ID: <4606B227B7AF19498F107C2C59CC9849B82B534D@EX10DAG10-N1>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_4606B227B7AF19498F107C2C59CC9849B82B534DEX10DAG10N1_"
MIME-Version: 1.0
archived-at: Fri, 24 Mar 2017 13:10:38 -0000

--_000_4606B227B7AF19498F107C2C59CC9849B82B534DEX10DAG10N1_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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: 'dev@lucenenet.apache.org'
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 w=
orking after the merge. I think it would be appropriate to change the pre-r=
elease label from "beta" to "beta2" (without resetting the build number, si=
nce 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 (hopeful=
ly) 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 ap=
plication that uses Lucene.Net. Reading from the configuration file directl=
y means no opportunity to use dependency injection. There is also a namespa=
ce Support/Configuration that can and should be removed after the implement=
ation 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 wa=
s 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 i=
cu-dotnet, and has been excluded from compilation using the constant FEATUR=
E_COLLATION. I am now convinced after reading the docs that it would be bet=
ter to port the similar functionality from Analysis.ICU because it was desi=
gned to work with icu4j and is therefore more likely to work with icu-dotne=
t.

4.       The Highlighter PostingsHighlight and VectorHighlight functionalit=
y relies on icu-dotnet, which doesn't have a close match for the BreakItera=
tor in the JRE, so there are likely some big differences in the functionali=
ty. Several hacks were put in to make the tests pass, but these are not lik=
ely to fix all of the issues in the wild.

5.       There are several namespaces in Lucene.Net.Core and Lucene.Net.Cod=
ecs 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 (avera=
ging 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 Z=
one, 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 a=
n 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 n=
ot 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 t=
ype of exceptions are being caught and the right type re-thrown.

5.       Fixed culture-sensitive comparison and sort order issues when usin=
g strings in Lucene.Net.Core and Lucene.Net.Codecs.

6.       Merged similar functionality in Support into the same class and de=
leted several unused Support classes.

7.       Made the API CLS compliant, so it now works with all .NET language=
s.


Shad Storhaug (NightOwl888)

--_000_4606B227B7AF19498F107C2C59CC9849B82B534DEX10DAG10N1_--