lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: State / Future of the Lucene.Net Project
Date Thu, 21 Jun 2018 08:15:28 GMT
On 2018-06-21, Shad Storhaug wrote:

> There are still many undecided issues regarding the ICU functionality. For example:

> 1. Should we use the newly ported ICU4N ( project
or try to add the functionality to the already existing project (
Note the latter has been attempted, but there are several issues (missing functionality, incompatibilities,
problems loading data) that make it very challenging to provide all of the Lucene.Net.ICU
functionality - it was easier to get it working by porting from ICU4J, but will require maintaining
the ICU4N project.
> 2. If we use ICU4N, should we make it into a general library that benefits all of the
.NET ecosystem, or should we limit it to primarily support Lucene.NET?

I'm not doing any of the work, so take this with a big grain of salt.

Right now I'd focus on what is best for Lucene.Net and try to safe the
(.NET) world later. To me it looks as if going with ICU4N in its current
state is the best short term option. If you want to turn ICU4N into
something useful then this sounds (1) very useful and (2) like a lot of
work. Most likely the people who'd want to contribute to ICU4N and
Lucene.Net are not the same (apart from yourself), so I'd separate
growing ICU4N from which version of ICU4N Lucene.Net should use. We can
probably switch to a more full-blown version of ICU4N if/when such a
beast eists. Most probably I'm missing something.

> Basically, there are 3 ways to complete this:

> 1. Add the required functionality to the project in order to support the Lucene.Net.ICU
features, port the missing Lucene.Net.ICU features to the current master branch and abandon
work on ICU4N.
> 2. Finish up the API and fix 19 failing tests to make ICU4N good enough to support Lucene.Net.ICU
without making it into a first-rate component that supports all ICU features.
> 3. Contact the ICU team about contributing ICU4N to their repository and if they agree,
allow them to lead the direction of the API and features (with the added possibility of their
help and Unicode expertise).

I'd opt for 2 - and 3 after 2 is done. But see the disclaimer above.


View raw message