lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wyatt Barnett <wyatt.barn...@gmail.com>
Subject Re: Proposal Stage: Backwards Compatibility / Support
Date Thu, 06 Jan 2011 07:58:03 GMT
Scripted, automated and repeatable are mantras to live by. Why not
take it all the way?

What I mean by this is setting up the new, fresh, Lucene 3.0 project
to do something like the following:

1) setup a CI server that grabs the current stable java source
automatically from SVN and runs our conversion tool [whatever it ends
up being] on said bits.
2) CI server then commits this to source control somewhere -- I'd
actually vote a branch per conversion here for a variety of reasons.
3) the actual lucene project references the automatically created bits
which can be merged in when we want to support a new drop from the
Java trunk.

This covers a few bases that would likely be pain points:

a) Keeps the conversion bits out of the .NET trunk. Meaning that most
users won't need [insert java toolz] to build/run the project. We are
just shipping C# here.
b) Makes it easy to fix on an exact java SVN revision we are based off
of. And makes it easy to change that revision should we need to
presuming we get the updated project organized right.
b) Will hopefully help us keep in lock step with the java bits going
forward -- we will at least be catching every update.

Thoughts?

On Wed, Jan 5, 2011 at 9:16 AM, Michael Herndon <mherndon@o19s.com> wrote:
> 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
View raw message