lucenenet-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shad Storhaug <s...@shadstorhaug.com>
Subject Re: State / Future of the Lucene.Net Project
Date Mon, 25 Jun 2018 15:53:43 GMT
Xiaokang,

As I mentioned, we have about 40% of it ported, which is all we need to support Lucene.Net.ICU.
The main focus should be cleaning up the API (starting with the public Enums, constants, and
many items marked "ICU4N TODO"). Note not all APIs in need of attention have been marked and
some that are we can skip for option 2 and make them internal. We just need to make the API
conform to .NET conventions.

We don't need to port any more types for option 2, and for option 3 we should really get the
ICU team involved first. The only exceptions are types we may need to port to make the tests
pass.

We can also just stick with version 60.1 for option 2 - make sure to checkout the correct
tag when doing comparisons.


Do note that the API of ICU4N has been modified some since Lucene.Net.ICU was last updated,
which is why it is different, but all of the pieces are still there and functioning. It will
need to be updated again once the API is at a stable point.

Let me know if there is anything you need.

Thanks,
Shad Storhaug (NightOwl888)



-------- Original Message --------
Subject: Re: State / Future of the Lucene.Net Project
From: 小康
To: user@lucenenet.apache.org
CC:

Hi, Shad.
I learn something about ICU4J ,Lucene.net.Analysis.ICU and ICU4N.
Making the ICU4N  have a complete function similar to ICU4J is a big job.
First,I will fix the function which is to support to
Lucene.net.Analysis.ICU.It is also a challenge for me.I will try to do it.
If I get some problem, I will contact with you.

Xiaokang(SilentCC)

2018-06-21 17:21 GMT+08:00 Shad Storhaug <shad@shadstorhaug.com>:

> Xiaokang,
>
> > 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?
>
> Yes.
>
> Thanks,
> Shad Storhaug (NightOwl888)
>
>
> -----Original Message-----
> From: 小康 [mailto:xiaokang@cnblogs.com]
> Sent: Thursday, June 21, 2018 3:41 PM
> To: user@lucenenet.apache.org
> Subject: Re: State / Future of the Lucene.Net Project
>
> Hi,
> 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 <bodewig@apache.org>:
>
> > 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 (https://github.com/
> > NightOwl888/ICU4N) project or try to add the functionality to the already
> > existing icu.net project (https://github.com/sillsdev/icu-dotnet)? 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 icu.net 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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message