lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <ita...@code972.com>
Subject Porting guidance
Date Sun, 20 Apr 2014 08:44:23 GMT
Hi all,

I've been going in a route that should allow us to port tests very easily,
I'd like to document the idea here and possibly have it made as standard.

It's been long decided that we will be .NET-ifying the API by pascal casing
names, converting setter/getter methods to properties (auto props where
possible), using Linq and yields instead of Java iterators etc. I think
there's still a lot of work to do there but that's for later.

The thing is we don't really want to have all this maintenance work for
tests as well. Ideally, we should be copy-pasting test classes, run a quick
command line tool / Visual Studio plugin / R# plugin to normalize a few
bits and then run the test.

The idea is to remove friction and non-important tasks from porting work.
While it does make a lot of sense to have a .NET-compatible API for the
library itself, we simply don't care about pascal casing for test classes
(or methods), nor do we care about the actual syntax there. As long as it
compiles, works and tests our code - I'm good with that!

So this is what I'm aiming for:

1. Support classes and methods in the test framework so we can compile Java
syntax. For example see:
https://github.com/apache/lucene.net/blob/branch_4x/test/test-framework/JavaCompatibility/SystemTypesHelpers.cs

2. A R# plugin I'm working on with a friend that is based on Paul Irwin's
library that will C#-standardize everything which cannot be compiled
(pascal casing, getter/setter to properties, remove throws declarations,
etc). Since this uses reflection it will work pretty nicely. This should
resolve 99% of the rest of the compilation issues.

3. Copy pasting of Java Lucene test classes should now (mostly) just work.

4. We can maintain test classes by automated scripts that detect git
changes etc. This will allow us to dedicate most of our resources to actual
library porting

I'll be happy to hear your opinions, but assuming we agree on the above,
here are the action items for moving forward:

1. All code ported to the test-framework should NOT be standardized to C#.
For example this from Michael's recent commit:
https://github.com/apache/lucene.net/commit/23d1c0ac8604157b5975db4a8b34ac388b67c982#diff-1c97ea7db55add0d01e3b62d13df70d5R409

We should just use rarely() and newDirectory() and so on, this will allow
us to just copy-paste tests that are using this (a lot!) without doing
anything fancy with them.

2. Since most of the tests are currently commented out / not included in
the project, we should start bringing them in again using the
aforementioned process. The end result should be all Java test classes as
compiled C# ones against Lucene.NET. There's a lot of infrasturcture
missing too, like the randomized testing Michael has started porting.

3. Integrating with a CI server, Travis for instance offers hosting for
free. This means we get to test our compilation on Mono, too!

That's it for now - let me know your thoughts

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Author of RavenDB in Action <http://manning.com/synhershko/>

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