This is a heads up -- I will be submitting a patch in a few hours that
corrects all outstanding compilation, javadocs, and checkstyle warnings,
which together produced about 2200 warning and error messages. This patch
changes around 400 files, so it is pervasive. It also incorporates the prior
patc
It seems to me the following:
Glenn, perhaps you could submit a separate de-warning patch or patches
against trunk. That could be reviewed, applied, and downmerged into
the complex script work. That might make this more manageable to the
committers. I would also respectfully wonder if diffing the
I don't plan to do any refactoring, just fixing warnings. The point of this
is to be able to easily find new warnings introduced, and doing so is quite
impractical with the current number of extant warnings. If we can get to a
state of no warnings, then perhaps we can attempt to maintain that state
We have two outstanding branches. All changes you make in this work
will, after they have been merged into trunk, be propagated to those
branches. I would prefer to restrict the work to the new
functionality, and not include other refactoring/correction of
warnings. Although I admit that co
it may be difficult to agree on a particular checkstyles policy, and I
really don't want to force creating or agreeing on such a policy, e.g., i
don't like to break lines for some arbitrary limit and i use nested blocks
and inline assignment, while others may not like that; however, i try to
respec
. 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 ze
Hi Glenn,
(Moving to general@ as maybe this is something we want to do at the XML
Graphics project level. Please continue discussion there.)
Thanks for bringing up this topic. I personally agree that
a zero-warning policy would be A Good Thing. In theory newly committed
code should have no Checks
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 o
