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'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 y
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
