Re: Proposal Stage: Backwards Compatibility / Support
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 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: 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 >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 > > > >
Re: Proposal Stage: Backwards Compatibility / Support
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 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 > 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: 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 > >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...@
Re: Proposal Stage: PR/Marketing/Branding
Some ideas to pursue: 1) Get lucene into nuget. Given nuget has Microsoft's weight behind it, it is going to become the defacto way people find .NET libraries. This is relatively simple -- pretty much packaging the binaries with an xml file. We could the current release in there today, and follow with 2.9.2 when we get it nice and official-like. 2) Build some approachable getting started guides. In all honesty, the only "how do I start using Lucene" stuff I found when I started using lucene six or so months ago was in Simone Chiaretta's blog plus the subtext source. This could perhaps include some DimeCasts.NET style stuff. Hope this helps. On Fri, Dec 31, 2010 at 4:26 PM, Michael Herndon wrote: > *PR/Marketing/Branding:* > Even open source need this. Its never something totally the forefront on the > developers mind, but its going to be key in order to build a community. > > The main part of marketing to strategically build connections between people > and a product/service so that they associate a particular brand name with a > particular solution. (Kinda like a conditioned response). > > Basically there is two products, the actual code base and the community > behind the codebase. > > I'm not saying we need ads on google, facebook, but providing good > documentation, a good work environment (making it fun), giving people > straight answers, having constructive dialog, treating others with respect, > staying responsive to the community will help to create a positive > connection in people's mind with lucene.net and search and community. > > Thats something that needs to happen given that people might question its > stability due to going back to incubation, the drop off in commits, etc. > > Any ideas, suggestions, comments, are welcome. > > * > * > > -- > Michael Herndon > Senior Developer (mhern...@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 >
Re: Proposal Stage: Net Idiomatic Api Version
Anyone else get the feeling that Java and C# are kind of like British and American english -- two people separated by a nearly common language? As for inspiration, RavenDb might be a good place to start. It has native Lucene querying capabilities and the API is quite sexy and has a number of good people designing and beating on it. On Tue, Jan 4, 2011 at 7:44 PM, Prescott Nasser wrote: > > I think good documentation, examples that have best practices is key to > fostering a good Lucene.Net community. No question in my mind that we would > do this. > ~Prescott > > > >> Subject: RE: Proposal Stage: Net Idiomatic Api Version >> Date: Tue, 4 Jan 2011 12:32:45 -0500 >> From: stema...@brain-bank.com >> To: lucene-net-dev@lucene.apache.org >> >> Peter, >> >> I completely agree - upon reading my last post it lacked a critical >> component to actually bring some value to the conversation which you >> mentioned. The USING keyword is key, perhaps as Robert mentioned it may >> not be in the best of lights given the context of the example but that >> is indeed how it should be used in the .NET framework. >> >> Perhaps the documentation for Lucene.NET can include examples that >> demonstrate the use of some of the expensive classes implemented as >> Singletons - perhaps even code that up for the client as part of the >> library itself (or in code examples). Clumsy coders would then not be >> able to "mess up" the performance of Lucene.NET as much as they could >> given their broad control over some of these objects and their lifetime. >> >> >> >> Karell Ste-Marie >> C.I.O. - BrainBank Inc >> >> >> -Original Message- >> From: Peter Mateja [mailto:peter.mat...@gmail.com] >> Sent: Tuesday, January 04, 2011 12:15 PM >> To: lucene-net-dev@lucene.apache.org >> Subject: Re: Proposal Stage: Net Idiomatic Api Version >> >> Robert... good points all. I especially agree that basing initial >> idiomatic work on 3.0+ makes sense (indeed, I believe this is what >> Lucere.Net had agreed to do.) >> >> Use of IDisposable can certainly lead to worst practices concerning >> IndexReader / IndexWriter objects. However, the IDisposable pattern (if >> implemented correctly... see >> http://msdn.microsoft.com/en-us/library/b1yfkh5e.aspx, >> http://www.codeproject.com/KB/dotnet/idisposable.aspx and Framework >> Design Patterns book mentioned earlier), really is the best way (in >> .Net) to ensure proper handling of both unmanaged resources, and >> stateful managed resources. >> >> I think a good combination of documentation and examples could do much >> to discourage worst practices. In some cases, the sample 'using' code >> you refer to might be appropriate... though in most the lifetime of an >> IndexWriter object might be controlled at a higher context (AppDomain, >> etc.) Let's ensure that Lucene.Net users know the how and why for each >> approach. >> >> Peter Mateja >> peter.mat...@gmail.com >
