Hi!
I was really careful when I checked my stuff in yesterday. I have the Eclipse checkstyle plugin running. I did run checkstyle via build script before checking in. I even runned ant freshstart junitAll which took forever. The only thing which I didn't do is starting a manual cruise-control build. I really can't see that I did something wrong.
Ok: But why is there an error: In the file which caused the error, I had the line * @version $Id$ in my javadoc header.
AFTER checking it in, CVS changed the line internally to * @version $Id: FreeMarkerTransformerPoolableObjectFactory.java,v 1.1 2005/04/13 08:56:27 christoph Exp $ As you can see, this is much longer that 100 characters. And it failed chackstyle. I see no way how I could see that before checking. The only thing I could have done is a running manual cruise-control build and wait for it to finish or checking all my files, check them out again and run checkstyle after checking again (which seems weird to me). I think I can try running a manual cruise-control after each checkin to prevent that thing.
Christoph
Philip Johnson wrote:
--On Wednesday, April 13, 2005 3:28 AM -1000 [EMAIL PROTECTED] wrote:
Hackystat build (configuration Hackystat-UH) failed. Build report is available at http://xenia.ics.hawaii.edu/hackyDevSite/configurationBuildReport.do?year
=2005&month=4&day=13&configuration=Hackystat-UH Build Time Stamp: Wed Apr 13 03:28:29 HST 2005
OK, this is yet another checkstyle failure in hackyCGQM, again due to Christoph. This brings up an interesting opportunity to reflect on software process.
The last time this happened, I asked Christoph to think about what he could change in his process, and he replied to me with "I'll try harder". This didn't seem like a good answer to me (I always assume that we all work as hard as we can), but I decided to just let it go.
However, it's now clear that Checkstyle daily build failures are a chronic problem for Christoph, no matter how hard he tries to avoid them. It's not about "trying hard", it's about working differently.
Some questions for Christoph: when do you run Checkstyle? Are you using our Ant system to build Hackystat? When do you use it? How do you perform commits of the system? How can you change your behavior so that you don't perform commits without doing a checkstyle? Our build contains an Ant task to do commits--should we provide a different one for you that depends upon Checkstyle that you can use to guarantee that Checkstyle is always run before you commit?
Since Checkstyle is such a problem for you, another idea is for you is to install the Checkstyle plugin for Eclipse and configure it so that you see Checkstyle violations immediately.
Please respond to the list with your thoughts on how you intend to implement this 'defect prevention'.
And, of course, fix the checkstyle errors in the current build!
Cheers, Philip
