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
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Author of RavenDB in Action <http://manning.com/synhershko/>
On Thu, May 1, 2014 at 9:42 AM, Simon Svensson <[email protected]> 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/lucene.net (added remote as origin)
2) I've added another remote for apache/lucene.net 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/lucene.net? Or are we pushing directly to apache/lucene.net?
The best way to work is by creating branch-per-feature or porting job or
whatever and then sending a PR to apache/lucene.net. 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 lucene.net 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
