lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Svensson <>
Subject Re: Porting questions
Date Thu, 01 May 2014 13:17:37 GMT

Regarding the extension methods mentioned at the end, I'm talking about 
introducing such a class/helper into the core Lucene.Net assembly for 
use of non-test assemblies. Those I've found so far 
(JavaCompatilibity/*.cs in Lucene.Test.Framework) are for tests only. 
Your mails from April 20th indicate that the purpose of such helper 
methods are for quick porting of tests only.

One example would be the java substring function. I've been bitten 
several times (and never seem to learn) that the parameters are 
different between java and .net.

         [Obsolete("Call String.Substring instead. Note that Java uses 
start+end while .NET uses start+length")]
         public static String substring(this String value, Int32 start, 
Int32 end) {
             return value.Substring(start, end - start + 1);

On another line of thought, are there any code formatting rules or 
plugins that helps? I believe Resharper/StyleCop supports storing code 
formatting settings in a file that can be commited so we're producing 
similar looking code. Or should we start a religious war about curly 
braces and whitespaces? ;)

// Simon

On 01/05/14 14:23, Itamar Syn-Hershko wrote:
> inline
> --
> Itamar Syn-Hershko
> | @synhershko <>
> Freelance Developer & Consultant
> Author of RavenDB in Action <>
> On Thu, May 1, 2014 at 9:42 AM, Simon Svensson <> wrote:
>> Hi,
>> I've once again woken up thinking that I should stop lurking and start
>> coding.
>> Could someone confirm that I am going about this in a correct way?
>> 1) I've forked the repository to sisve/ (added remote as origin)
>> 2) I've added another remote for apache/ named upstream
>> 3) I'm using the branch named "branch_4x"
> yes
>> Q: Do we work by coding in our personal repos and sending pull request to
>> apache/ Or are we pushing directly to apache/
> The best way to work is by creating branch-per-feature or porting job or
> whatever and then sending a PR to apache/ Then notify us in the
> mailing list (or open a JIRA ticket, but I think discussions on the GitHub
> repos are much easier to work with).
> After discussions and possibly some revisions (by pushing more commits to
> your branch) we can merge to branch_4x in upstream and once it will be
> synced with the github mirror (it takes it 30 mins or so) the PR will be
> automatically marked as closed.
>> Q: Is the mirroring against the apache-hosted repository
>> automatic?
> Yes
>> When opening the Lucene.Net.sln file, hosting only Lucene.Net,
>> Lucene.Net.Tests and Lucene.Net.TestFramework, I have a suspiciously low
>> number of tests, only 24 (of which 3 fails). (At least it compiles.)
> Someone (I think Paul) removed them from the solution, and the work now is
> on bringing them back in mostly by re-porting them
>> Q: Am I doing something wrong, or is this the current state?
>> Since I've had some run-ins with the hunspell analyzer (a long long time
>> ago) I thought that I should look into the contrib solution and see what's
>> needed. I'm quickly informed by Resharper's solution-wide analysis "[n]
>> errors in [m] files", where [n] and [m] > 0.
>> I'm thinking that the first step is to introduce a big
>> PortingHelper.cs-file with extension methods matching the java api, forward
>> them to the correct .net api (usually just casing- or minor changes), and
>> marking these helper extension methods as obsolete. This would both allow
>> stuff to compile, and give hints to whoever ports/fixes the classes about
>> the ".net way" to do whatever is being done. This PortingHelper.cs-file
>> should not be present when we're done (doh!).
>> Q: Does this seem reasonable? The goal is to make everything compile (even
>> with obsolete-warnings) so that the tests can tell the status of things.
> Please read up on the mailing list and look at the most recent commits. We
> are already doing that.
>> // Simon

View raw message