lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Martz <benma...@gmail.com>
Subject Re: Lucene.NET Community Status
Date Mon, 01 Nov 2010 23:12:21 GMT
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:nicw@fastchicken.co.nz]
>> Sent: Monday, November 01, 2010 3:32 PM
>> To: lucene-net-user@lucene.apache.org; anmum@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<anmum@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:digydigy@gmail.com]
>>> Gesendet: Montag, 1. November 2010 22:32
>>> An: lucene-net-user@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:philha@microsoft.com]
>>> Sent: Monday, November 01, 2010 11:12 PM
>>> To: lucene-net-user@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:digydigy@gmail.com]
>>> Sent: Monday, November 01, 2010 2:02 PM
>>> To: lucene-net-user@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:philha@microsoft.com]
>>> Sent: Monday, November 01, 2010 10:26 PM
>>> To: lucene-net-user@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$d6g$1@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.ffffc7d5@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
>>
>

Mime
View raw message