synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hubert, Eric" <Eric.Hub...@foxmobile.com>
Subject RE: Offer to support Synapse development
Date Mon, 16 Mar 2009 07:06:44 GMT
Hi,

 

I don't know too much about the corresponding Maven2 plugins and in
which phase of the lifecycle they normally operate, but I have a very
knowledgeable colleague who also did our Hudson setup. So I can easily
get all the needed information. I agree that it does not make sense to
run those reports with every build. It takes time and consumes
resources. In Hudson we do have a special documentation job accompanying
each build job which by default runs only once a day. From my
perspective this is totally sufficient to collect quality metrics and
let tools check for bad practice and bug patterns.

The integration in Hudson is therefore useful, as it offers a very
convenient way to obtain those reports and also important check the
trend conveniently. The tricky part is the selection/configuration of
rules/rulesets to apply. My suggestion: start with a rather small set
and increase it incrementally. The same configuration as used in CI
should be used inside the IDE with the respective plugins. Most
favourite IDEs have nowadays rather sufficient support for those tools.

 

Regards,

   Eric

 

________________________________

From: Ruwan Linton [mailto:ruwan.linton@gmail.com] 
Sent: Sunday, March 15, 2009 10:33 PM
To: dev@synapse.apache.org
Subject: Re: Offer to support Synapse development

 

I too agree with Eric here, though they seem to be doing the same thing,
each of these have it's own focuses and I would like to see all three
reports. Thanks Eric for the nice explanation.

So, how are we planning to execute this? Are we going to use the
respective maven plugins, if so I would suggest using a different
profile for these reports without affecting the normal build flow.
AFAIK, these reports are generated at the reporting phase of the maven
execution, but of course FindBugs and PMD comes at the compile phase to
collect the information to be presented in the report.

Thanks,
Ruwan

On Mon, Mar 16, 2009 at 2:31 AM, Hubert, Eric
<Eric.Hubert@foxmobile.com> wrote:

> Cool!
>
> Now, probably it doesn't make sense to use both PMD and findbugs,
> especially if we use annotations to suppress specific warnings. Do you
> have an idea which one is better?

>From my personal experiences this is not true. It makes sense to use
both of them in parallel, because although there is in fact some
overlapping, they have strength and weaknesses in different areas. It is
possible to configure them in a way to reduce the overlapping (not
suppressing rules in code, but exclude some rules from the applied
ruleset of each tool). Overall PMD is a bit more useful in CI where
Findbugs can also help if executed on demand.
Findbugs detects bugs, which PMD can't (bytecode versus source code
analysis). Number of false positives is higher for Findbugs.

A while back a colleague prepared a presentation. One picture was quite
useful to demonstrate the different focus of those tools. I attached it
to the mail. Hope it comes through...
Actually we ended up integrating Checkstyle, PMD and Findbugs in CI.

Additionally to the picture here some of my experiences regarding the
strength/weaknesses of the tools:

Checkstyle
----------
Focus: CONVENTIONS
Naming, code format, consistence code/JavaDoc, design suggestions

Pro:
+ good for big, distributed teams to achieve style consistency
+ some design metrics are pretty useful to improve the code (decrease
complexity)

Contra:
- configuration always necessary
- if used in conjunction with code formatter, rules need to be adjusted
to avoid conflicts
- if a project has been setup without checkstyle right from the
beginning, IDE integration can be painful due to too many violations
"for peanuts" (whitespace problems, tab instead of space etc.); rules
should then be applied stepwise


PMD
---
Focus: AVOID BAD PRACTICES
Identifies useless control flow, find missing freeing of resources,
suggestions for performance improvements, identifies redundant checks
etc.

Pro:
+ very good explanation of each violation (including reasoning and hints
to do it better
+ grouping of rules to rulesets
+ highly customizable (rules in editable xml)
+ extendable (Java/XML knowledge needed)

Contra:
- depending on the ruleset, PMD can also output a great number of
warnings


Findbugs
--------
Focus: FIND POTENTIAL BUGS

Pro:
+ identifies real bugs (NPE, Death Store, multithreading problems due to
wrong synchronization)

Contra:
- number of false positives (problems with compile optimizations,
dependency injection etc.)


Very interesting is also what's going on in the sonar open source
project:
http://sonar.codehaus.org/

Here you can find something in action:
http://nemo.sonar.codehaus.org/

They also think that all the above tools are valuable and try to
integrate their results.

They have also a Hudson plugin available, but I did not find time to
investigate:
http://sonar.codehaus.org/a-new-hudson-plugin-for-a-closer-integration-w
ith-sonar/


Regards,
 Eric


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org




-- 
Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB;
http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com 


Mime
View raw message