<<By the way, why does LuceneTestCaseJ4 extend TestWatchman and also a instance field extends that class?>> No good reason, I plead confusion when figuring out how to use it. I've attached a patch to Lucene 2037 that removes the LuceneTestCaseJ4 extending TestWatchman.
<<I do not understand the whole magic behind, this is totally confusing to me – annotating a field that is never used in code by an annotation is stupid and looks totally incorrect (I mean the field holding the TestWatchman-subclass).>> Well, this is to provide the same functionality as LuceneTestCase. I'm reaching a bit here since I haven't been in that code lately, but... LocalizedTestCase called runBare in LuceneTestCase which reported the seed value if an exception was thrown. I couldn't find a good way to access runBare or analogs in Junit4, but the interceptor pattern worked as well. The interceptor is called by the Junit framework on test events, so there aren't references to it in the Lucene test code. There are other places that call runBare, so I assumed that if anyone wanted to use Junit4 with those classes it would be a good thing to allow. I think the interceptor pattern is an elegant way to "do something" at discrete points in the test run, although it is a bit opaque. Most of this was put in when I was trying to move LocalizedTestCase to the Junit4 world. We didn't do that, but this still needs to be kept if we want LuceneTestCaseJ4 to be a drop-in replacement for LuceneTestCase. <<< - This is another thing why I am against the migration of our already proven tests.>>> If you'll recall the discussion at the time, neither am I. I do believe, though, that if anyone wants to change a test class to use Junit4 it's a good thing to have something that'll drop in without surprises, which is what I was trying for. Erick
