OK, Christoph, you get an A++ for effort!
Some hints:
- Don't worry about cruise control, this problem has nothing to do with them.
- This kind of checkstyle failure is definitely a boundary case. It occurs only
when
checking in a file with a long name for the first time.
- To prevent daily build failures from this situation, all you have to do is:
(a) Add all of the new files and commit all of the changed ones.
This will automatically update your local copy with the new CVS $Id$
string.
(b) % ant checkstyleAll
This will reveal the error.
(c) Fix filenames that are too long.
(d) Add new files, delete old ones that had a too long file name.
(e) % ant checkstyleAll
To verify everything is OK now. Of course, you might want to do an 'ant
freshStart junitAll' just in case.
- It may take some effort to restrain yourself from 50+ character file names,
but I'm
sure you can do it. Sometimes, a filename that strings together four or five
different
words indicates a class that is trying to accomplish too much.
Cheers,
Philip
p.s. Of course, none of this explains today's hackyCGQM junit failure! :-(
--On Wednesday, April 13, 2005 10:30 AM -1000 Christoph <[EMAIL PROTECTED]>
wrote:
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
