Github user NightOwl888 commented on the issue:
https://github.com/apache/lucenenet/pull/191
Update
===
Build
---
I fixed the build issue by adding a NuGet.config file (thanks for the
suggestion @conniey). I also pushed a commit to fix the physical directory
locations of the Lucene.Net.Sandbox and Lucene.Net.Tests.Sandbox locations.
These commits are now on the
https://github.com/NightOwl888/lucenenet/tree/spatial and
https://github.com/NightOwl888/lucenenet/tree/queryparser-xml respectively, so
merging them here should go smoother.
Hopefully, that will get all of these updates out on MyGet in the nightly
build (fingers crossed).
ThaiTokenizer
----
I noticed that the ThaiTokenizer on this branch is setup for `en-US`, when
the [original Java version was setup for
`th`](https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.8.0/lucene/analysis/common/src/java/org/apache/lucene/analysis/th/ThaiTokenizer.java#L42).
The only reason it was made into English was because ICU4NET didn't have an
option for Thai. I am not sure if it makes a difference, but if it is possible
to specify `th` or `th-TH` that would be closer to the original implementation.
Next
----
Work is almost complete on the Highlighter (which I will submit as a PR
here).
I think that next I should help you get this branch caught up to master so
we can merge it.
Afterward, I would like to focus on getting the breaking API changes done
ASAP so they are behind us. I am running out of time to dedicate to this
project (or at least I will have to stop working on it full-time soon) and I
would like to get that part completed. If we can't get this merged to master
soon, I will just work from this branch and stop making changes in master so
these sweeping changes can be merged more easily.
My thoughts on the API are to make it as close to Lucene as possible, and
leave that as a low-level API. Then, start coming up with a plan to create a
higher level APIs to cover the most common use cases (similar to the way
[SimpleLucene](https://simplelucene.codeplex.com/documentation) did but with a
broader scope). Ultimately, we should probably create high-level integration
packages for various frameworks (ASP.NET, MVC, WebApi, WPF, etc) so everyone
that uses Lucene.Net doesn't have to rewrite the same boring configuration code
and so Lucene.Net can be configured using the standards in those frameworks
(such as with DI and via extension methods). And of course, these high-level
APIs should ideally be setup so they don't need to change (additions only) when
the next version of Lucene is ported.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
