I think the 100% Sharpen is more to mean, it should be 100% automatic conversion including pre/post processing scripts so that future translations can be quick, easy, and as error free as possible. If you replace 100% Sharpen with 100% Java 2 CSharp Translator I think Troy's intent stands. As for Sharpen specifically - I think it comes from when we were trying back in mid November to get it up and going, it was the only free option we could find. The eclipse plugin I haven't seen before, but should definitely be evaluated. As for Tangibles - I actually like their software (I've used their VB.Net -> C# for a few projects), but I couldn't get a copy for testing purposes - and unless we can get a free licenses for the project, I don't like the idea of requiring a piece of not free software as part of our conversion process. ~P
> 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 > > > > >
