--On Monday, February 14, 2005 9:19 AM -1000 "(Cedric) Qin ZHANG" <[EMAIL PROTECTED]> wrote:
I did freshStart and junitAll for all module before committing.
The problem is, when testing build sensor, I set checkstyle.failOnViolation=false,
So when junitAll finishes, all checkstyle errors have already scrolled up the console window (nowhere to find).
Hmm. So, looks like knowing what targets are invoked won't be good enough for your build analysis if people can basically disable their results! There's no point in running checkstyle, for example, if the results are ignored.
I think the larger moral of the story is that the ability to disable Checkstyle failure was intended for use only in the daily build mechanism (so we could still get other reports and a distribution even if checkstyle failed).
It's not, however, appropriate for regular developers to disable checkstyle or junit failure. As yesterday's build illustrates, eventually this results in project-wide problems.
So, two defect prevention-related proposals: - Cedric, this seems to indicate to me that we were wrong in our previous approach to defaults. The default should always be to fail. - Everyone should simply delete (or at least comment out) the checkstyle.failOnViolation and the junit.haltonfailure properties in their local hackystat.properties file. In combination with appropriate defaults, this will prevent the cause of last night's build failure from occuring in future.
Cheers, Philip
