Good suggestions, it's really helpful to have someone intimately familiar with the code suggest the next direction. I didn't want to go too far afield for the proof-of-concept, I mostly wanted to have a place to start. LuceneTestCaseJ4 should be useful both as a template and a base to build with. If you wanted to put in a JIRA or two and assign them to me I'd be happy to take a look. I'm pushing this off on you since you have a better sense of what's important here....
About reformatting. I'm torn, for all the reasons I'm certain you can quote. Of course I'll abide by the sense of the community, but "the community" doesn't speak with one voice. Michael McCandless and I had an exchange on this very topic and he is in the opposite camp. I guess I was heavily influenced by Martin Fowler's "Refactoring" book and the eXtreme Programming folks.... What I'd personally like would be for someone with heavy commit privileges to reformat the whole thing at once and just get it *done*, as was apparently discussed at ApacheCon. Eclipse makes this easy. I'd also like to be wealthy.... Look at the bright side, I'm not trying to convince anyone that "my way of formatting is obviously superior because I put braces on their own line" <G>.... Best Erick On Sun, Nov 15, 2009 at 6:16 AM, Uwe Schindler (JIRA) <j...@apache.org>wrote: > > [ > https://issues.apache.org/jira/browse/LUCENE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778086#action_12778086] > > Uwe Schindler commented on LUCENE-2037: > --------------------------------------- > > One thing that would also be good: > We have LocalizedTestCase, which has the possibility to run each test for > all available Locales (it overrides currently runBare() and iterates while > setting Locale.setDefault()). As this test should only be ran for specific > methods, how about adding a annotation in addition to @Test (with > Retention("method") like @TestLocalized. > > What to do with BaseTokenStreamTestCase? In 2.9 it had also overridden > runBare(), but not anymore (because we only have the new TS API anymore), > but this is also a typical example when we want to rerun tests multiple > times. One on our plan is that this test now runs all analyzer test for > different default versions (iterate over Version enum constants). We need > then something like @TestAllVersions or something like that. If we jump to > JUnit4, we should use the new features for a more elegant solution of these > multiple-run tests. > > One note: It would be good to *not* reformat the whole tests with an > Eclipse cleanup, just change the lines you modified, not reformat everything > or organize imports and so on. Its hard to find out what has changed. > > > Allow Junit4 tests in our environment. > > -------------------------------------- > > > > Key: LUCENE-2037 > > URL: https://issues.apache.org/jira/browse/LUCENE-2037 > > Project: Lucene - Java > > Issue Type: Improvement > > Components: Other > > Affects Versions: 3.1 > > Environment: Development > > Reporter: Erick Erickson > > Assignee: Erick Erickson > > Priority: Minor > > Fix For: 3.1 > > > > Attachments: junit-4.7.jar, LUCENE-2037.patch > > > > Original Estimate: 8h > > Remaining Estimate: 8h > > > > Now that we're dropping Java 1.4 compatibility for 3.0, we can > incorporate Junit4 in testing. Junit3 and junit4 tests can coexist, so no > tests should have to be rewritten. We should start this for the 3.1 release > so we can get a clean 3.0 out smoothly. > > It's probably worthwhile to convert a small set of tests as an exemplar. > > -- > 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 > >