lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lombard, Scott" <slomb...@KINGINDUSTRIES.COM>
Subject RE: Proposal Stage: Backwards Compatibility / Support
Date Tue, 04 Jan 2011 21:37:12 GMT
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:digydigy@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 <geobmx540@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: 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
> > >
> > >
> >
>
>


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.

Mime
View raw message