I would lean towards open source conversion tools since having a robust one would be useful beyond Lucene. I haven't dug into the sharpen code yet to see what it would take but I could see creating our own fork of sharpen.
The original conversion I did had a little pre-processing just to get around some sharpen bugs. It's documented in the issue. -----Original Message----- From: Prescott Nasser [mailto:geobmx...@hotmail.com] Sent: Sunday, January 02, 2011 4:23 PM To: lucene-net-dev@lucene.apache.org Subject: RE: Proposal Stage: Backwards Compatibility / Support Here is a Sharpen conversion Alex Thompson did in November: https://issues.apache.org/jira/secure/attachment/12459581/Lucene.Net.Sharpen 20101114.zip >From my understanding there was no pre/post processing done. I also believe it's 2.9.2, not 3.0.3 as Digy's are. Here is the JIRA issue for the associated conversations: https://issues.apache.org/jira/browse/LUCENENET-380 > From: geobmx...@hotmail.com > To: lucene-net-dev@lucene.apache.org > Subject: RE: Proposal Stage: Backwards Compatibility / Support > Date: Sun, 2 Jan 2011 13:36:49 -0800 > > > Also, was there any pre/post processing involved in these files? Was it manual / scripts etc? Just trying to get a feel for the work involved. > > > > From: digyd...@gmail.com > > To: lucene-net-dev@lucene.apache.org > > Subject: RE: Proposal Stage: Backwards Compatibility / Support > > Date: Sun, 2 Jan 2011 19:03:25 +0200 > > > > > The 3.0.X ports should be 100% Sharpen > > Why? > > What about other alternatives? > > > > Lucene.java 3.0.3 ==> .Net Conversion Samples ( > > http://people.apache.org/~digy/Lucene.Net.3.0.3.zip ) > > > > DIGY > > > > > > > > -----Original Message----- > > From: Troy Howard [mailto:thowar...@gmail.com] > > Sent: Saturday, January 01, 2011 1:58 AM > > To: lucene-net-dev@lucene.apache.org > > Subject: Re: Proposal Stage: Backwards Compatibility / Support > > > > We are inheriting the outstanding issues facing the Lucene.Net project. > > > > This includes remaining committed to providing a line-by-line port > > that stays in sync with the Java Lucene releases. > > > > The project is currently extremely behind schedule on this. The > > 2.9.2 code base, which is widely used and thus a fairly well > > received build, has never been formally packaged as a release (i.e. > > binary builds, etc). This is the first order of business to take > > care of (in terms of code). > > > > After that we need to evaluate weather or not to create releases to > > match all subsequent releases made by the Java Lucene project. > > > > Those releases are: > > - 3.0.0 > > - 3.0.1 > > - 2.9.3 > > - 3.0.2 > > - 2.9.4 > > - 3.0.3 > > > > In the interest of time, we could skip some of the intermediate > > releases and just get in sync at 2.9.4 and 3.0.3 releases. > > > > The 3.0.X ports should be 100% Sharpen conversions and > > post-processing scripts. Once written, anyone should be able to > > repeat the process of pulling down the appropriate Java Lucene SVN > > revision, executing the porting scripts, and building the resulting > > .NET code, yield a valid 3.0.X release with a 1:1 matching API. > > > > This is something we will need to continue being able to do for > > every subsequent Java Lucene release. > > > > This aspect of our development should be completely separate from > > our refactoring/re-imagining of a more .NET-like API. They need to > > be separate development branches, and possibly even completely > > different implementations. We will attempt to reuse as much of the > > automated port code as we can, with the understanding that the goal > > of the secondary branch is to make a high-quality .NET > > implementation of Lucene, rather than a API compatible implementation. > > > > Thanks, > > Troy > > > > > > > > On Fri, Dec 31, 2010 at 3:29 PM, Alex Thompson <pierogi...@hotmail.com> wrote: > > > Maybe we could just bug-fix support the current 2.9.2 codebase > > > unless people really need something in 2.9.x > > > > > > I think there would be a 3.0.x line-by-line port and a 3.0.x > > > idiomatic version. > > > > > > I'd like to throw another idea into the mix which is perhaps the > > > idiomatic version could be created by an automated refactoring of > > > the line-by-line. It might be additional upfront work but might > > > make it easier for future changes from java lucene to be propagated down. > > > > > > Alex > > > > > > -----Original Message----- > > > From: mhern...@amptools.net [mailto:mhern...@amptools.net] On > > > Behalf Of Michael Herndon > > > Sent: Friday, December 31, 2010 1:28 PM > > > To: lucene-net-dev@lucene.apache.org > > > Subject: Proposal Stage: Backwards Compatibility / Support > > > > > > *Backwards Compatibility / Support: * This is definitely something > > > we need to cover. > > > > > > I'm guessing the obvious choice would be to continue the 2.9.X > > > versions under sharpen, maintain the current api thats has java > > > idioms so that people can continue to use it, release patches, > > > ensure stability with the current community. This would be > > > important for people who have built products on top of lucene.net. > > > > > > The 3.0 version should probably match java in terms of breaking > > > the api due to the language changes or maybe even a separate project inside: > > > lucene.netredux (for lack of a better term at the moment). > > > > > > > > > * > > > * > > > -- > > > Michael Herndon > > > > > > > > >
