Re: [Ginp-developers] Project Quality

[Brian B. <br...@Pi...>]

Well, things didn't work out quite so well in practice. I did a "mvn 
site" against your latest source and CheckStyle threw out more than 7800 
errors!

I took ~/commands/Logon.java as a typical example and started to fix the 
errors manually. Fixing one would usually cause another to pop out and 
replace it. By the time I'd spent an hour, I hit a major snag because we 
did not have the Apache Copyright statement in our source!!! I realised 
there was something fundamental going wrong. How could we be using and 
enforcing Sun coding conventions if we needed an Apache copyright?

Well, several days later I've worked a lot of this out. It is a pity 
there isn't better documentation on the web - or if there is, I couldn't 
find it with google.

I followed your tracks to start with. I found out how to run Jalopy and 
decided the only sensible option was a single-shot from the 
command-line. Eventually, I found some instructions on how to create my 
own Jalopy configuration file by running the preferences.sh gui; 
incorporate our own copyright statement; then export the xml file. I 
then ran Jalopy against the source - I couldn't get recursion to work so 
I ran it directory-by-directory.

In the middle of my Jalopy experiments, I kept running "mvn 
checkstyle:checkstyle" to monitor my progress. CheckStyle did not appear 
to be applying the Sun coding standards - at least not the same ones as 
Jalopy!

Eventually I took a CVS snapshot of sun-checks.xml from the CheckStyle 
source and modified pom.xml to use it. That wasn't any good because it 
needed a valid DTD. I found the correct doctype statement, pasted it in 
and checkstyle ran OK with a BIG reduction in the error count.


So, here is the situation. I have used Jalopy to reformat all the source 
according to explicit Sun standards. It looks MUCH better to my eye, 
e.g. opening curlies on the same line, fewer spaces in argument lists, 
etc. It might not be perfect, but it is good enough to live with. Sorry 
to say that every source module now looks different to the versions that 
you checked-in last week...

I've also put my jalopy-ginp.xml file into the source tree, even though 
it isn't (and shouldn't) be used by maven, it is worth keeping for 
documentation purposes. Besides, we might want to tinker with it in 
future (or rip it off for other projects).

I've put my working checkstyle-ginp.xml file in the source tree too, and 
now pom.xml uses it when running CheckStyle.

Currently, we still have 1404 style errors after a clean/test/site 
sequence. I've reviewed quite a few and they appear to be reasonable and 
worth fixing. I won't go into detail, but some are of more concern than 
others.

I'm ready to commit all these changes. I intend to do it in two chunks - 
the xml's first, then all the updated java source files. I don't think 
it is worth the effort of regressing your changes, so I would commit 
against the latest version. Are you happy for me to go ahead?

Regards,

Brian

p.s. I haven't yet run Jalopy against the test classes, but would do 
once the main classes were mostly cleaned up.