lucenenet-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prescott Nasser <geobmx...@hotmail.com>
Subject Re: State / Future of the Lucene.Net Project
Date Mon, 25 Jun 2018 16:55:10 GMT
Hey James -

You can unsubscribe by sending an email to

User-unsubscribe@lucenenet.apache.org

Best
Prescott
________________________________
From: James Lewis <witchlightning@gmail.com>
Sent: Monday, June 25, 2018 9:36:09 AM
To: user@lucenenet.apache.org
Subject: Re: State / Future of the Lucene.Net Project

Please take me off this list.

Cheers,
James
representi.com



On Mon, Jun 25, 2018 at 8:53 AM Shad Storhaug <shad@shadstorhaug.com> wrote:

> 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