The people who make Sonar host Apache projects for free. Many Apache
projects have Sonar set up there, and can get findbugs and all sorts of
other useful data without individual contributors running these tools.

Having written that ...

for what it's worth, I am personally opposed to taking the default output of
'findbugs' as gospel. Many of the things that it reports are 'bugs' only in
the eyes of its authors or the religious.

On other projects I've worked on, the project has come up with an agreeable
set of checkstyle and/or PMD rules that are treated as 'normative', but
findbugs output is hard to treat as anything except a report that you can
read and consider whether any particular item deserves to be addressed.
Aiming for a perfect score there seems unrealistic.

Meanwhile, I am, completely off to one side, curious as to why you think
that maven is a 'big' solution. Sheer disk space of the downloaded
components? Something else? I build CXF on a rather wimpy MacMini at home
from time to time. It is thirsty for permgen space when you use certain
plugins, but plain old compiling has never struck me as that different from


On Mon, Aug 16, 2010 at 9:34 AM, Simon Pepping <>wrote:

> Glenn,
> Thanks for this interesting report.
> I noted that the problems reported here are harder to fix. They often
> touch upon design issues. See my efforts on the warnings for clone,
> Probably,
> when a codebase has no findbugs problems, it has a clean OO design.
> But for a code base with a long history and many authors, that is
> hardly feasible. Moreover, where would we find the time and budget to
> do all this work?
> I also noted that findbugs is too big for my simple machine. I do not
> develop FOP as a profession, so I do not have a larger machine for
> this purpose alone. There goes findbugs into the same corner as maven:
> for professionals only.
> Simon
> On Sun, Aug 15, 2010 at 04:40:47AM +0800, Glenn Adams wrote:
> > First, I wish to express my pleasure that checkstyle (5.1 at least) now
> > reports zero warnings/errors, and that only four deprecation warnings are
> > present at compile time. This is a significant improvement in code
> > cleanliness, and I hope that all committers will take the time to run
> > checkstyle and resolve new warnings before performing new commits.
> >
> > However, as I mentioned in a previous messge, there remain a fairly large
> > number of warnings/errors reported by findbugs: 922 of them to be exact.
> I
> > don't plan to take any action myself on these at the present time, since
> > I've managed to stir up the pot (and emotions) quite adequately with my
> > prior patch. However, if others wish to start addressing these issues,
> > perhaps incrementally over time, then we can move the code base even
> closer
> > to a zero warning state, or at least a state where we've audited all the
> > warnings adequately. To this end, I am attaching the current findbugs
> report
> > as a matter of interest. Because findbugs reports more potentially
> serious
> > semantic problems in the code, it is also likely that more potential real
> > bugs will be uncovered and addressed.
> --
> Simon Pepping
> home page:

Reply via email to