lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Thompson <pierogi...@hotmail.com>
Subject RE: Proposal Stage: Backwards Compatibility / Support
Date Mon, 03 Jan 2011 02:00:29 GMT
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:geobmx540@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: geobmx540@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: digydigy@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:thoward37@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 <pierogitus@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: mherndon@amptools.net [mailto:mherndon@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
> > >
> > >
> > 
>  		 	   		  
 		 	   		  


Mime
View raw message