lucenenet-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shad Storhaug <>
Subject RE: State / Future of the Lucene.Net Project
Date Thu, 21 Jun 2018 09:21:30 GMT

> I want to try the #2 first. And if possible , I want to help making ICU4N
> into a general library  with option #3.

Sure, starting with #2 for now and then doing #3 later is also a possibility.

In that case, we should make a few types internal so as not to expose APIs that will later
be refactored as .NET-Like (ICU4N.Util.ULocale and ICU4N.Lang.UCharacter for example, which
correspond to Java types that will later need to be ICU4N.Globalization.UCharacterInfo and
ICU4N.UChar to correspond the same way in .NET). We will need to mark them with an "ICU4N
TODO: Change from internal back to public" comment to make sure when they are ported over
to the correct place we make them public again.

> I think I need to do some preparation.
> I will try do this job in my free time and I have confidence to do it.

There are several tasks that can be done only being familiar with C# and .NET APIs and how
to design them. For example, we should convert all Enums from having UPPER_CASE elements into
TitleCase as is done in the rest of .NET (they are mostly already done, with a few remaining).

We also have several APIs that are accepting "options" or "flags" as integers, many of which
should be converted into Flags Enums.

Once you begin doing regular .NET cleanup tasks, you begin learning the project structure
and more complex tasks become easier. Also, ICU is very well documented, so it just takes
research to work out how some things need to be done.

> Will I contact with you in this way in the future?


Shad Storhaug (NightOwl888)

-----Original Message-----
From: 小康 [] 
Sent: Thursday, June 21, 2018 3:41 PM
Subject: Re: State / Future of the Lucene.Net Project

I think I need to do some preparation.
I will try do this job in my free time and I have confidence to do it.
Will I contact with you in this way in the future?

2018-06-21 16:15 GMT+08:00 Stefan Bodewig <>:

> 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 (
> NightOwl888/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.
> Stefan
View raw message