I've wondered about that myself. I tried working with the Trunk and got countless warnings. They included dead code, deprecated methods, and unused assigned variables among other things. To sift through you could go into project specific compile options in Eclipse and tell it to ignore them if you have the project created as source. There may be an option to ignore on the ant build that's not as obvious but clean code would be appreciated, even as much as I appreciate the dirty code if the warnings don't crash anything and it got some useful features implemented faster. I would hope there's less urgency to implement now that the project has passed the 1.0 mark and code can be kept clean.
________________________________ From: Glenn Adams [mailto:gl...@skynav.com] Sent: Tuesday, August 03, 2010 4:27 AM To: FOP Developers Subject: fixing and maintaining zero reported warnings policy? Would anyone mind if I submit a patch that fixes all the outstanding warnings, etc., reported during the build process and by checkstyles and findbugs on the trunk? More importantly, if I do this, is it possible to adhere to a zero tolerance policy on warnings for future commits? I find the 3000 or so warnings currently produced to be a rather significant impediment to doing work on this code base, or at least, in preventing an avalanche of new warnings upon future commits, given the trouble required to determine the diffs between new warnings and old warnings. Perhaps this isn't a problem for changes to one file, but for changes to a hundred files, it is a major headache. Anyway, some of these 3000 are actually real, lurking bugs. I'm willing to do the cleanup work if others will help maintain cleanliness going forward. Regards, Glenn