I'm glad that my previous email appears to not have gone through since at first 
glance this solution appears to be much more mature that what I have been 
looking at. Thanks for the links guys.

Igor Latyshev wrote:

Sharpen from db4o seems to be an open source tool:

http://developer.db4o.com/Blogs/Product/tabid/167/entryid/94/Default.aspx

(there's a link to source code repository at the bottom of the page)

Igor

On 01/11/2010 22:37, Phil Haack wrote:
Anyone know which translator does the best job? Perhaps we should decide which 
is our preferred tool for translation (maybe with a #2 and #3 backup) and if 
cost is an issue, we can tackle that together. It seems to me that helping out 
with the cost is something that a foundation ought to help with. :) But if the 
Apache foundation doesn't pony up the money for the software, maybe we can ask 
around. I'd be happy to see if I know any companies that can help with 
sponsorship to purchase a license for such software.

Phil

-----Original Message-----
From: Nic Wise [mailto:n...@fastchicken.co.nz]
Sent: Monday, November 01, 2010 3:32 PM
To: lucene-net-u...@lucene.apache.org; an...@online.de
Cc: lucene-net-dev@lucene.apache.org
Subject: Re: Lucene.NET Community Status

Damn, you bet me to it. I was just about to post the same thing.

http://foodformonkeys.blogspot.com/2010/10/ngit.html

It was used here (recently - over the weekend I think) to port JGit into NGit

I'd stick my hand up - having use Lucene.Net on projects from multi-million 
dollar packaged products (Quest Archive Manager) to websites (www.topgear.com) 
and various other places - but I'm about to leave on a 3 month trip away, with 
limited internet for a lot of it....  So I'll have to see where things are when 
I get back...


On Mon, Nov 1, 2010 at 22:26, Andreas Mummenhoff<an...@online.de>  wrote:
Hi Digy,

maybe you know db4o, which is available for Java and .Net. As far as I
know, the development is done in Java and the .Net port is done with
an automated tool. I don't know if it's public available, one thing I
found is
(http://developer.db4o.com/Projects/html/projectspaces/db4o_product_de
sign/s
harpen.html).
Anyway, it's for sure that they maintain only one code base and
generate the .Net version from the java code, which is even quite
.Netified. So it must be possible to do automated conversion!!!


There is also another project on sourceforge that allows to translate
java to c#:

http://sourceforge.net/projects/j2cstranslator/


Another tool I found is

http://tangiblesoftwaresolutions.com/Product_Details/Java_to_VB_and_CS
harp_C
onverter_Details.html

I know another product of this company, Instant C# / Instant VB, which
do a very good job.

And of course we can look into http://www.artinsoft.com/so_j2ee.aspx,
which was proposed from George Aroush.


Maybe the afford is worth trying to get an automated tool running (for
example taking j2cs and tweak it to support special Lucene-cases). So
the next step could be to work not on Lucene.Net directly, but
developing an automated translation process. This in turn could open
the future for other wishes (for example translating setXXX, getXXX into 
properties).

What do you think?

And if there is some resistance with commercial tools, I could donate
some money for the license, and I'm sure other's will do as well, so a
few hundred $ will not be the problem.




Andreas


-----Ursprüngliche Nachricht-----
Von: Digy [mailto:digyd...@gmail.com]
Gesendet: Montag, 1. November 2010 22:32
An: lucene-net-u...@lucene.apache.org
Betreff: RE: Lucene.NET Community Status

Simply "No" for all your question. I have no tools for automating this
process.

How does NHibernate and other .NET ports handle this?
Good question :)

DIGY


-----Original Message-----
From: Phil Haack [mailto:phi...@microsoft.com]
Sent: Monday, November 01, 2010 11:12 PM
To: lucene-net-u...@lucene.apache.org
Subject: RE: Lucene.NET Community Status

Hi Digy,

I saw George Aroush's response on what it takes to do the port. I
didn't realize how much effort it was to just get the port working.
Hypothetically speaking, are there code translators that do a good
enough job of porting the code where there would be time to spend on a
tiny bit of clean up to .NET idioms?  That way, for each major
version, you do the port and then do a tiny bit of cleanup. Forgive my 
ignorance in this area.

How does NHibernate and other .NET ports handle this?

Trying to understand the logic and rewrite in .NET seems like a
gargantuan task. I'm certainly no search expert and am not up to the
task. ;) However, what automated test coverage do you have. Is it
pretty substantial? Is it possible to run the Java Lucene tests
against the .NET code? I ask because at the very least, a small amount
of deviation form the line by line would be mitigated by such tests.

Phil

-----Original Message-----
From: Digy [mailto:digyd...@gmail.com]
Sent: Monday, November 01, 2010 2:02 PM
To: lucene-net-u...@lucene.apache.org
Subject: RE: Lucene.NET Community Status

Hi Phil,

I see your point, but there is no easy "hybrid" way.
What would you do if you wanted to port a new version of java code?
* Searching for differences from the current version and trying to
apply those changes to the current code Or
* Trying to understand the logic and rewrite the code

The 2nd approach needs a great community as lucene.java does.
The 1st one needs a "similar" code to "see" the differences easily(I
haven't found an automated way).



DIGY




-----Original Message-----
From: Phil Haack [mailto:phi...@microsoft.com]
Sent: Monday, November 01, 2010 10:26 PM
To: lucene-net-u...@lucene.apache.org
Subject: Lucene.NET Community Status

Hi All,

Sorry to jump in the middle of a conversation like this, but I've read
the thread on this and wanted to point out a couple of things in the
hopes of being more helpful than not :)

The goal of Lucene.NET has in the past been to be a line by line port
of Lucene for the following reason posited by Robert Jordan
(http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-user/20101
1.mbox /raw/%3ciam8c3$d6...@dough.gmane.org%3e/). He says:

You're missing the point. Lucene.NET is "just" a port of Lucene With
a .NET-like API. The searching expertise is still there where it
belongs: to the main Lucene project. If you want "new approaches in
search" then you're looking at the wrong project.
As Jeff Rodenburg (a former committer) points out, the reason for this
approach was
(http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-user/20101
1.mbox
/raw/%3c4ccf0425.0f958e0a.1c26.ffffc...@mx.google.com%3e):

keeping the Lucene.Net codebase on par line-by-line with the
Java-based project would facilitate easier maintenance of the
codebase
over
time; as the Java version received improvements, one could implement
the same in C#, and the project would benefit all the same.
But it seems to me the very fact we're even having this conversation
at all (and given the fact that.NET implementation is far behind the
Java
implementation) shows that this strategy isn't working. At least not
in its current form.

But we can't discount the importance and magnitude of Robert's point.
The Java Lucene community is and will continue to do the heavy lifting
when it comes to search expertise. Thus I see the benefits of staying
true to some degree to the Lucene codebase. But I wonder if some
carefully targeted divergence could help breathe new life into the
project. Perhaps some sort of hybrid approach that loosens this line
by line requirement? Some have mentioned having the internals be
closer to the line-by-line but the public surface area fit more .NET.
Even parts of the internals could be .NETified to a small degree as
long as it's clear where the original source was from and with sufficient test 
automation.

After all, the project is *already* not keeping up with the Java version.
Perhaps by making the library more ".NET Friendly", the extra cost to
do the port is more than outweighed by the extra involvement of people
who want to see the project stay alive.

I'm pretty swamped with my other OSS projects, but Lucene.NET is
important to me personally so I would like to help in any way I can.

Phil





--
Nic Wise
t.  +44 7788 592806 | @fastchicken | http://www.linkedin.com/in/nicwise
b. http://www.fastchicken.co.nz/ | http://www.flickr.com/photos/nicwise


Reply via email to