Andrey, I urge you to use JIRA for this. That's exactly what it's for and how it gets used.
Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: Andrey Klochkov <akloch...@griddynamics.com> > To: solr-user@lucene.apache.org > Sent: Thursday, May 7, 2009 5:14:26 AM > Subject: Re: Creating new QParserPlugin > > Hi! > > I agree that Solr is difficult to extend in many cases. We just patch Solr, > and I guess many other users patch it too. What I propose is to create some > Solr-community site (Solr incubator?) to public patches there, and Solr core > team could then look there and choose patches to apply to the Solr codebase. > I know that one can use Jira for that, but it's not convinient to use it in > this way. > > On Thu, May 7, 2009 at 2:41 AM, KaktuChakarabati wrote: > > > > > Hello everyone, > > I am trying to write a new QParserPlugin+QParser, one that will work > > similar > > to how DisMax does, but will give me more control over the > > FunctionQuery-related part of the query processing (e.g in regards to a > > specified bf parameter). > > > > In specific, I want to be able to affect the way the queryNorm (and > > possibly > > other factors) interact with a > > pre-computed value I store in a static field (i.e I compute an index-time > > score for a document that I wish to use in a bf as a ValueSource, without > > being affected by queryNorm or other such extranous considerations.) > > > > While trying this, I notice I run alot into cases where some parts I try to > > override/inherit from are private to a java package namespace, and this > > makes the whole thing very cumbersome. > > > > Examples for this are the DismaxQParser class which is defined as a local > > class inside the DisMaxQParserPlugin.java file (i think this is bad > > practice > > - otherwise, FunctionQParserPlugin/FunctionQParser do have their own > > seperate files, so i think this is a good convention to follow generally). > > Another case is where i try to inherit from FunctionQParser and end up not > > being able to replicate some of the parse() logic, because it uses the > > QueryParsing.StrParser class which is a static inner class and so is only > > accessible from the solr.search namespace. > > > > In short, many such cases seem to arise and i think this poses a > > considerable limitation on > > the possibilities of extending solr. > > If this resonates with more people here, I'd take this issue up with > > solr-dev. > > > > Otherwise, if some of you have some notions about going about what i'm > > trying to do differently, > > I would be happy to hear. > > > > Thanks, > > -Chak > > -- > > View this message in context: > > http://www.nabble.com/Creating-new-QParserPlugin-tp23416974p23416974.html > > Sent from the Solr - User mailing list archive at Nabble.com. > > > > > > > -- > Andrew Klochkov
