Hi Rory, I agree with you in theory. But collecting people to work on a project is not easy as giving advise. Till now, line-by-line port have seemed to be the best with a limited human source.
Would you be willing to work on your approach and maintain newer Lucene.Net releases? DIGY -----Original Message----- From: Rory Plaire [mailto:codekai...@gmail.com] Sent: Thursday, June 30, 2011 1:06 AM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? For what it's worth, I've participated in a number of projects which have been "ported" from Java to .Net with varying levels of "translation" into the native style and functionalty of the .Net framework. The largest are NTS, a JTS port and NHibernate, a Java Hibernate port. My experience is that a line-by-line port isn't as valuable as people would imagine. Even if we discount the reality that a line-by-line port is really unachievable due to various differences between the frameworks, keeping even identical code in sync will always take some work: full automation on this large of a project is infeasible. During manual effort, therefore, making readable changes to the code is really not that much more work. For update maintenance, porting over code from recent versions of both projects to the .Net versions, and ".Nettifying" that code is little trouble. Since both projects use source control, it's easy to see the changes and translate them. When it comes to debugging issues, in NTS or NHibernate, I go to the Java sources, and even if the classes were largely rewritten to take advantage of IEnumerable or generics or structures, running unit tests, tracing the code, and seeing the output of each has always been straightforward. Since I'm using .Net, I'd want the Lucene.Net project to be more .Net than a line-by-line port of Java, in order to take advantage of the Framework as well as provide a better code base for .Net developers to maintain. If large .Net projects ported from Java do this, and have found considerable success, it is, in my view, a well-proven practice and shouldn't be avoided due to uncertainty of how the resulting code should work. Ultimately, that is what unit tests are for, anyway.
