The only Java 5 thing in core is LUCENE-2052, for which I find no Eclipse plugin. So "grep" with heavy regex is needed and maybe an UnexpectedSuccess on finding some more varargs.
The current tests are not converted to generics, but that is really unimportant because it is not public API. Robert: I think the contrib things are the only leftovers. ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de _____ From: Robert Muir [mailto:rcm...@gmail.com] Sent: Wednesday, November 11, 2009 1:32 AM To: java-dev@lucene.apache.org Subject: Re: Release 3.0 soon Hi Uwe, I think we all appreciate the heavy committing you have done for 3.0! With regards to the java 5 issue, I think all that is left is contrib? Is there any more work in core to be done for java 5 in 3.0? On Tue, Nov 10, 2009 at 7:24 PM, Uwe Schindler <u...@thetaphi.de> wrote: Hi other developers, I am still on heavy committing, but I think we have fixed almost everyting for Lucene 3.0. The public API uses generics, enum, varargs,...; all deprecations scheduled for 3.0 are removed. The following issues are still open: Key Summary Assignee LUCENE-1558 <https://issues.apache.org/jira/browse/LUCENE-1558> Make IndexReader/Searcher ctors readOnly=true by default Michael McCandless LUCENE-1370 <https://issues.apache.org/jira/browse/LUCENE-1370> Patch to make ShingleFilter output a unigram if no ngrams can be generated Karl Wettin LUCENE-1948 <https://issues.apache.org/jira/browse/LUCENE-1948> Deprecating InstantiatedIndexWriter Karl Wettin LUCENE-1973 <https://issues.apache.org/jira/browse/LUCENE-1973> Remove deprecated query components Uwe Schindler LUCENE-2052 <https://issues.apache.org/jira/browse/LUCENE-2052> Scan method signatures and add varargs where possible Uwe Schindler LUCENE-1845 <https://issues.apache.org/jira/browse/LUCENE-1845> if the build fails to download JARs for contrib/db, just skip its tests Simon Willnauer LUCENE-1698 <https://issues.apache.org/jira/browse/LUCENE-1698> Change backwards-compatibility policy Michael Busch LUCENE-2024 <https://issues.apache.org/jira/browse/LUCENE-2024> "ant dist" no longer generates md5's for the top-level artifacts Unassigned LUCENE-2047 <https://issues.apache.org/jira/browse/LUCENE-2047> IndexWriter should immediately resolve deleted docs to docID in near-real-time mode Michael McCandless LUCENE-2050 <https://issues.apache.org/jira/browse/LUCENE-2050> Improve contrib/benchmark for testing near-real-time search performance Michael McCandless LUCENE-2051 <https://issues.apache.org/jira/browse/LUCENE-2051> Contrib Analyzer Setters should be deprecated and replace with ctor arguments Unassigned LUCENE-1081 <https://issues.apache.org/jira/browse/LUCENE-1081> Remove the "Experimental" warnings from search.function package Unassigned LUCENE-1909 <https://issues.apache.org/jira/browse/LUCENE-1909> Make IndexReader.DEFAULT_TERMS_INDEX_DIVISOR public Grant Ingersoll The red one is finished, I just wait for comments or something against. The yellow one needs to be discussed. The other ones are simple fixes that should be resolved soon. I left out the Java-5-Issue, because it is a neverending story (you can always find unneeded casts, generics warnings,.), but the import thing is, that the public API is generified. Everything else can be easily fixed after release of 3.0. LUCENE-1558 has one problem: The methods were deprecated in 2.9, but reappear with different behaviour in 3.0, which is bad. Maybe we should add them in 3.1 again, so users coming from 2.9 will not see strange behaviour. Else it should be marked red in the changes backwards section, that the methods were undeprecated, because they are no longer the same methods like before and now have different behaviour. So something like: "was deprecated in 2.9 because no support for the previous behaviour anymore. Readded in 3.0 as "new methods". I want to start the release process during the weekend (my first tests as release manager), so I can throw out RC1 on next Monday or so. Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -- Robert Muir rcm...@gmail.com
