From user-return-4398-archive-asf-public=cust-asf.ponee.io@lucenenet.apache.org Mon Jun 25 17:53:57 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id DEFC4180627 for ; Mon, 25 Jun 2018 17:53:56 +0200 (CEST) Received: (qmail 65734 invoked by uid 500); 25 Jun 2018 15:53:55 -0000 Mailing-List: contact user-help@lucenenet.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@lucenenet.apache.org Delivered-To: mailing list user@lucenenet.apache.org Received: (qmail 65721 invoked by uid 99); 25 Jun 2018 15:53:55 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Jun 2018 15:53:55 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id D19AE1808DF for ; Mon, 25 Jun 2018 15:53:54 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2 X-Spam-Level: ** X-Spam-Status: No, score=2 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id Pzxz2GUehPBC for ; Mon, 25 Jun 2018 15:53:51 +0000 (UTC) Received: from ex10cshbfe01.apps4rent.net (ex10cshbfe01.apps4rent.net [69.160.246.194]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with SMTP id 442AC5F35A for ; Mon, 25 Jun 2018 15:53:51 +0000 (UTC) Received: from EX10DAG10-N1.apps4rent.net ([10.10.10.123]) by EX10CSHBFE01 ([10.10.10.113]) with mapi id 14.03.0319.002; Mon, 25 Jun 2018 08:53:44 -0700 From: Shad Storhaug To: "user@lucenenet.apache.org" Subject: Re: State / Future of the Lucene.Net Project Thread-Topic: State / Future of the Lucene.Net Project Thread-Index: AQHUCTgD5rUKkFO8B0SSLiEPy+KQhqRq2hyA//+QWfCABxoZgP//omX9 Date: Mon, 25 Jun 2018 15:53:43 +0000 Message-ID: <458A3CD4F362D144B999930AAADEBAAD2F83B3B3@EX10DAG10-N1> References: <87vab7pyr7.fsf@v45346.1blu.de> <458A3CD4F362D144B999930AAADEBAAD2F839A94@EX10DAG10-N1> <458A3CD4F362D144B999930AAADEBAAD2F839D11@EX10DAG10-N1> <87y3f8d07z.fsf@v45346.1blu.de> <458A3CD4F362D144B999930AAADEBAAD2F83A050@EX10DAG10-N1>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_458A3CD4F362D144B999930AAADEBAAD2F83B3B3EX10DAG10N1_" MIME-Version: 1.0 --_000_458A3CD4F362D144B999930AAADEBAAD2F83B3B3EX10DAG10N1_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Xiaokang, As I mentioned, we have about 40% of it ported, which is all we need to sup= port Lucene.Net.ICU. The main focus should be cleaning up the API (starting= with the public Enums, constants, and many items marked "ICU4N TODO"). Not= e not all APIs in need of attention have been marked and some that are we c= an skip for option 2 and make them internal. We just need to make the API c= onform to .NET conventions. We don't need to port any more types for option 2, and for option 3 we shou= ld 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 checko= ut the correct tag when doing comparisons. Do note that the API of ICU4N has been modified some since Lucene.Net.ICU w= as last updated, which is why it is different, but all of the pieces are st= ill 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: =1B$B>.9/=1B(B 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 : > Xiaokang, > > > I want to try the #2 first. And if possible , I want to help making ICU= 4N > > 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 API= s > that will later be refactored as .NET-Like (ICU4N.Util.ULocale and > ICU4N.Lang.UCharacter for example, which correspond to Java types that wi= ll > 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 "ICU4= N > 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 Enum= s > 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 ne= ed > to be done. > > > > Will I contact with you in this way in the future? > > Yes. > > Thanks, > Shad Storhaug (NightOwl888) > > > -----Original Message----- > From: =1B$B>.9/=1B(B [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 : > > > 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 alrea= dy > > 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 curren= t > > 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 enou= gh > > 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 > > > --_000_458A3CD4F362D144B999930AAADEBAAD2F83B3B3EX10DAG10N1_--