I already started with removing deprecations in o.a.l.store and make FSDir abstract. This package is finished, now I have to remove all these open()/ctors using getDirectory().
Will post a patch tomorrow! Good night! Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -----Original Message----- > From: Michael McCandless [mailto:luc...@mikemccandless.com] > Sent: Saturday, October 03, 2009 1:33 AM > To: java-dev@lucene.apache.org > Subject: Re: Lucene 2.9 and deprecated IR.open() methods > > Sigh. The introduction of new but deprecated methods is silly. Is > there some simple automated way to catch/prevent these? > > The proliferation of ctors/factory methods is a nightmare. > > Part of the story with IndexReader.open is the switch to readOnly > IndexReaders. After the long back-compat discussion we settled on > adding new ctors as the best way to make the change. > > On deprecation of Version.LUCENE_29, that doesn't seem right. In fact > I don't think LUCENE_24 should be deprecated, either, since these > constants are used by StandardAnalyzer to state compatibility that's > "equivalent" to index format compability (from our last discussion). > > I think deprecation by separate area makes sense? > > Mike > > On Fri, Oct 2, 2009 at 6:41 PM, Uwe Schindler <u...@thetaphi.de> wrote: > > When looking for press articles about the release of Lucene 2.9, I found > the > > following one from Bernd Fondermann > > @ http://it-republik.de/jaxenter/artikel/Apache-Lucene-2.9-2594.html > > > > Translation with Google Translate: > > ------------------------------------------------------------------------ > ---- > > Deprecated > > > > An index reader is created via the static open () factory method, of > which > > there were 2.4 in all nine. Five of them are now deprecated. In 2.9 > there > > are now a total of 14 open-overloaded variants, with eight of them but > they > > are deprecated. This means that there are even some additions that have > been > > directly identified with introduction as deprecated - confusing. > > > > The constructor-Deprecation orgy goes for the standard Analyzer, one of > the > > key classes during indexing and querying further. This class has now no- > less > > constructor arguments over what might, perhaps, some downstream > libraries > > bring to stumble to instantiate their analyzer on a property, which > contains > > the class name dynamically. Instead, an object version must be given to > set > > for compatibility with 2.4 or 2.9. Both the VERSION_24 as well as the > > VERSION_29 parameters are deprecated but themselves - very confusing! > > VERSION_CURRENT is the only safe investment in the future, a value which > we > > certainly also as assignment in a zero-argument constructor would have > > trusted. > > > > To write an index we need an index writer instance. Again, the majority > of > > the 19 possible constructors are about to be put to retire to. > > ------------------------------------------------------------------------ > ---- > > > > What was going wrong with the open() hell in IR? Very strange, I should > have > > looked better. > > > > By the way: How to proceed with deprecation removal? Case-by-case (e.g. > > start with TS API, then these open() calls, then FSDirectory - to list > the > > ones I was involved) or some hyper-patch? > > > > By the way, here is my talk @ Hadoop GetTogether in Berlin: > > > > http://blog.isabel-drost.de/index.php/archives/category/events/apache- > hadoop > > -get-together-berlin > > > > Uwe > > > > ----- > > Uwe Schindler > > H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
