For number 2, you're spot on - free to the Lucene.Net project is probably the relevant piece. Someone mentioned having an open source tool that we could customize directly for our conversion purposes would be useful - but I think that really goes to 1 and 3 - if we can create pre/post processing scripts that uses a non open tool what does it matter. I hope people are working with the code digy linked to a few days ago to really evaluate the extend of the extra work required to get those to build (I know I have spent some time digging in and I would like to spend a bit more time). I also hope someone is taking a lead on the Sharpen convert - I don't have any of the stuff on my system, and don't really have any knowledge of it, so I am hesitant to jump in and try to make a 3.0.3 port - is anyone working on that? I don't think we need them to be buildable , but we need enough people familiar with the different options so that we can have an informed decision.
I would ask that everyone download digy's conversions and begin to play with those. I would also ask that someone who has sharpen or is familiar with it to please step up and do a quick conversion of lucene 3.0.3 and give the group a link to that. This would give us 3 conversion tools to evalute. If anyone can step up and do a 3.0.3 Sharpen conversion in the next couple of days please let us know, otherwise I will get started downloading /installing the required stuff and digging into Sharpen documentation, I think we need to get this ball rolling. Also, I'm not sure how quickly we need to make a decision, since Troy hasn't submitted a proposal to the ASF. I have no idea how long that process might take. ~Prescott > From: slomb...@kingindustries.com > To: lucene-net-dev@lucene.apache.org > Date: Tue, 4 Jan 2011 16:37:12 -0500 > Subject: RE: Proposal Stage: Backwards Compatibility / Support > > A couple of different packages have been mentioned for the conversion. What > criteria should be used to determine the best software to use? > > Given the items mention by troy. How do we metric these items for a > comparison? > > 1. Automated, Repeatable, and Well Documented (e.g. a script or build task > with minimal human involvement) > 2. Based on free, open source tools > 3. Performs a reasonable and high quality conversion that presents a > 1:1 API between Java/C# and the same functionality and performance > > Note: Number 2 might be changed to just the software being free to the > Lucene.Net project. > > How much up front work do we do to decide on the correct conversion tool? > Does the team think we need to get a working source from each tool and then > decide? Should we convert a single file? Should we convert an analyzer? > > > > Scott > > > -----Original Message----- > From: digy digy [mailto:digyd...@gmail.com] > Sent: Monday, January 03, 2011 2:26 AM > To: lucene-net-dev@lucene.apache.org > Subject: Re: Proposal Stage: Backwards Compatibility / Support > > No pre/post processing involved. They are just to see how the output of > these tools looks like. > > DIGY > > On Sun, Jan 2, 2011 at 11:36 PM, Prescott Nasser <geobmx...@hotmail.com>wrote: > > > > > 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 > > > > > > > > > > > > > > > > > > This message (and any associated files) is intended only for the > use of the individual or entity to which it is addressed and may > contain information that is confidential, subject to copyright or > constitutes a trade secret. If you are not the intended recipient > you are hereby notified that any dissemination, copying or > distribution of this message, or files associated with this message, > is strictly prohibited. If you have received this message in error, > please notify us immediately by replying to the message and deleting > it from your computer. Thank you, King Industries, Inc.
