lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Herndon <mhern...@o19s.com>
Subject Re: Proposal Stage: Backwards Compatibility / Support
Date Wed, 05 Jan 2011 14:16:38 GMT
I could probably take a stab at Sharpen this weekend. I need to pull down
the java version of lucene anyways.

On Wed, Jan 5, 2011 at 1:50 AM, Prescott Nasser <geobmx540@hotmail.com>wrote:

>
> 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: slombard@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: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.
>
>



-- 
Michael Herndon
Senior Developer (mherndon@o19s.com)
804.767.0083

[connect online]
http://www.opensourceconnections.com
http://www.amptools.net
http://www.linkedin.com/pub/michael-herndon/4/893/23
http://www.facebook.com/amptools.net
http://www.twitter.com/amptools-net

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message