Return-Path: Delivered-To: apmail-jakarta-lucene-user-archive@www.apache.org Received: (qmail 57665 invoked from network); 3 Nov 2004 08:25:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 3 Nov 2004 08:25:20 -0000 Received: (qmail 45509 invoked by uid 500); 3 Nov 2004 08:25:10 -0000 Delivered-To: apmail-jakarta-lucene-user-archive@jakarta.apache.org Received: (qmail 45464 invoked by uid 500); 3 Nov 2004 08:25:09 -0000 Mailing-List: contact lucene-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Users List" Reply-To: "Lucene Users List" Delivered-To: mailing list lucene-user@jakarta.apache.org Received: (qmail 45449 invoked by uid 99); 3 Nov 2004 08:25:09 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from [143.205.118.212] (HELO proserver2.ifit.uni-klu.ac.at) (143.205.118.212) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 03 Nov 2004 00:25:08 -0800 Received: from [143.205.118.98] ([143.205.118.98]) by proserver2.ifit.uni-klu.ac.at over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Nov 2004 09:25:05 +0100 Message-ID: <418895E1.6050201@ifit.uni-klu.ac.at> Date: Wed, 03 Nov 2004 09:25:05 +0100 From: sergiu gordea User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lucene Users List Subject: Re: How do Lucene applications deal with API changes? References: <04Nov2.165433pst."58617"@synergy1.parc.xerox.com> In-Reply-To: <04Nov2.165433pst."58617"@synergy1.parc.xerox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2004 08:25:05.0938 (UTC) FILETIME=[9F826720:01C4C17E] X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Bill Janssen wrote: >Thanks to Bill Tschumy, who points out that Lucene 1.4.21 *breaks* the >API exported by 1.4 by removing a parameter from >QueryParser.getFieldQuery(). That means that my >NewMultiFieldQueryParser also breaks, since it overrides that method. >To fix, just remove the Analyzer parameter from the getFieldQuery() >method in NewMultiFieldQueryParser. > >More generally, how is an application developer that wants to use >Lucene supposed to deal with these kinds of things? It's a micro >release, the change isn't noted in the CHANGES.txt file, and as far as >I can see, there are no version numbers in the jar file you could look >at during an application "configure". > >Does anyone have any successful ways of dealing with these kinds of >things? The only thing I can think of is to put a specific Lucene jar >in my app source code. > > what about writing a JUnit test? It can show when the code is broken. It's not too much improvement but it can be an improvement. I have a testcase ... for my parser .. maybe I can adapt it share the code. Sergiu >Bill > >--------------------------------------------------------------------- >To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org >For additional commands, e-mail: lucene-user-help@jakarta.apache.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: lucene-user-help@jakarta.apache.org