From: David S. <sa...@mi...> - 2006-03-15 15:30:41
|
Curt Arnold wrote: > The Gump (http://gump.apache.org) nightly builds for log4j have been > failing for the last few nights due to a suspected change in the junit > source code. Sorry about that. Let's get it fixed. > I attempted to check out the current CVS HEAD, but the system was > unresponsive. You're not the first to be frustrated by sourceforge's glacial anonymous cvs access over the last few months. I'm looking into whether we can get any kind of better guarantees from SourceForge. My apologies. > The lack of activity on the mailing list archive is also disconcerting. Is there a question that has gone unanswered? > I've updated the Gump metadata so that log4j builds against junit > 3.8.1 not the CVS HEAD and should know overnight if that avoids the > symptoms for now. You may want to try 4.0 (tagged r40) or 3.8.2 (tagged r382), which are the supported release versions. > The Gump build fails with: > > [junit] Testcase: org.apache.log4j.CoreTestSuite took 0.004 sec > [junit] Caused an ERROR > [junit] No runnable methods > [junit] java.lang.Exception: No runnable methods > > CoreTestSuite.java looks like: [snip] > What I assume is happening is that one of the classes in the calls to > addTestSuite does not contain any test methods or the inadvertent (and > just recognized) duplication of LoggingEventTest is resulting in an > exception that did not occur with junit prior to a few days ago. In > either case, the "No runnable methods" message is of very little help > in analyzing the problem. It would be helpful at least if the "No > runnable methods" message would include the name of the class that was > being examined for runnable methods. Yuck. Can you give me more information about the ant task that is running the tests? I'd love to know why ant has decided to filter out all but the least useful information provided by JUnit. > Unfortunately log4j is a bear to set up to build since it involves a > large number of Sun and third-party dependencies. I haven't been able > to reproduce the problem on my local machines using log4j jars from Gump. So when you run it locally, the tests appear to pass? |