lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From NightOwl888 <...@git.apache.org>
Subject [GitHub] lucenenet issue #191: Migrating Lucene.Net to .NET Core
Date Sat, 10 Dec 2016 21:06:30 GMT
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message