Junit4: Well, simply disliking the @Test annotation seems like a poor reason to stay with Junit3, although I admit it's a pain in the neck to change. Which is why I didn't try to change all of them. The current system lends itself to the practice of mangling the test name as a way of not running it, which far too easily allows the test case to be forever ignored. One concrete advantage of annotations in Junit4 is the ability to add another "stupid" annotation @Ignore, which then gets reported and thus doesn't get lost.
As I remember, that last place we left localization what that Mike (?) saw some intermittent problem that I couldn't reproduce. I could dust off that code and see what the current state of affairs is since this has come up again. The other problem was that the implementation I used lead to *increased* test run times. The localization tests basically spun through all the Locales available and ran all the tests in the class against them. The current system only runs *some* of the tests in a test class through the localization process. This can be addressed by, at worst, splitting the test class up, but in my proof-of-concept that seemed like too much detail... My purpose in deprecating LuceneTestCase was to explicitly encourage migration to Junit4, the deprecation warnings being the goad. I vote against removing it.... FWIW Erick On Thu, Feb 25, 2010 at 10:54 AM, Uwe Schindler (JIRA) <j...@apache.org>wrote: > > [ > https://issues.apache.org/jira/browse/LUCENE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12838384#action_12838384] > > Uwe Schindler commented on LUCENE-2285: > --------------------------------------- > > Hi Shai, > > I applied the patch to my checkout, so it will not get out-of date. As > mentioned before, I have to review each change, as on my first diagonal > look-around I found a removed cast in TestCharArraySet/Map that is important > to call the right method, without the cast the test would pass, but the > affected method is never called. I am also not want to remove some casts in > NumericRange and other parts, where the casts were added for more clearness > in code. Especially at some places without the cast it is not clear what > javac will do, so the cast is for more "security" even if not needed. > > So please excuse by complaints, but two people looking over such a large > patch is really needed. > > Thanks for the work! Uwe > > > Code cleanup from all sorts of (trivial) warnings > > ------------------------------------------------- > > > > Key: LUCENE-2285 > > URL: https://issues.apache.org/jira/browse/LUCENE-2285 > > Project: Lucene - Java > > Issue Type: Improvement > > Reporter: Shai Erera > > Assignee: Uwe Schindler > > Priority: Minor > > Fix For: 3.1 > > > > Attachments: LUCENE-2285.patch > > > > > > I would like to do some code cleanup and remove all sorts of trivial > warnings, like unnecessary casts, problems w/ javadocs, unused variables, > redundant null checks, unnecessary semicolon etc. These are all very trivial > and should not pose any problem. > > I'll create another issue for getting rid of deprecated code usage, like > LuceneTestCase and all sorts of deprecated constructors. That's also trivial > because it only affects Lucene code, but it's a different type of change. > > Another issue I'd like to create is about introducing more generics in > the code, where it's missing today - not changing existing API. There are > many places in the code like that. > > So, with you permission, I'll start with the trivial ones first, and then > move on to the others. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
