lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <>
Subject Re: Porting questions
Date Thu, 01 May 2014 20:02:33 GMT
Yes, this is why we are working towards having a good R# plugin that will
let us do Java to C# porting easily, taking into account things like you
mention. This may already be supported by Paul's library by the way, and if
it isn't it can certainly be added to it. The R# plugin we plan on having
will be based on that. I hope to have more news in the upcoming weeks.

Personally I couldn't care less about curly brackets, but we should decide
on whitespaces/tabs and use stylecop or similar to enforce that, for
readability sake


Itamar Syn-Hershko | @synhershko <>
Freelance Developer & Consultant
Author of RavenDB in Action <>

On Thu, May 1, 2014 at 4:17 PM, Simon Svensson <> wrote:

> Outline!
> 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

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