tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ro├čbach>
Subject Re: svn commit: r960104 - /tomcat/trunk/test/org/apache/catalina/mbeans/
Date Wed, 07 Jul 2010 16:53:18 GMT

I miss the checkstyle and findbugs quality checks in the project.

Marc has contributed a good starting point at

Then I can check my personal problem with the tab/space replacement,  
before checkin code :-)
Currently we have in 144 files a tab instead a space replacement  
issue. Ok, I want to fix it.

Later we can add more checkstyles. Who wants to help, me?

In the last two years we made a lot of source code cosmetic changes  
and these help to get a more readable codebase.
I think that Marc Guillemot can help us to get more code and test  
quality to the project.

What does the other developers think?


Am 05.07.2010 um 11:34 schrieb Mark Thomas:

> On 05/07/2010 09:27, Marc Guillemot wrote:
>> wrote:
>>> Author: markt
>>> Date: Fri Jul 2 21:13:25 2010
>>> New Revision: 960104
>>> URL:
>>> Log:
>>> A few more FindBugs issues
>> > ...
>> why don't you integrate checkstyle (and FindBugs) in the build?
> The Tomcat code doesn't follow any standards consistently so the  
> number of warnings that would get reported is huge. As far as I am  
> aware the actual problems have been fixed. The remaining issues are  
> cosmetic. There may be some real issues hiding in there somewhere  
> but if there are, they aren't things that users are reporting as  
> problems else there would be a bugzilla entry for it.
> I don't think (I could be wrong) there is much interest in investing  
> a lot of effort in a bug code clean-up. Gradual improvement seems to  
> be the preferred approach at the moment.
>> It's the only safe way to ensure quality
> I don't think it is as black and white as that. These tools have  
> their place and I think the Tomcat project has used them  
> appropriately. FindBugs, for example, still reports 1000s of issues  
> but the actual problems were fixed quite some time ago. The cosmetic  
> issues were not.
> There is a valid argument that fixing the cosmetic issues does more  
> harm than good by making it harder to do diffs between major versions.
>> and to avoid useless style discussions.
> I don't recall any useless style discussions. I don't think this is  
> an issue we need to solve.
> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message