Re: sonar code review

2014-12-04 Thread Andrus Adamchik
Cool. And we also have a bunch of code reports printed to stdout during the build. Just that we didn't have time yet to tweak them and analyze what remains. Once we do it, we can even force the builds to fail if they do not conform to the rules. Andrus > On Dec 4, 2014, at 9:44 AM, Aristedes

Re: sonar code review

2014-12-04 Thread Michael Gentry
I kind of agree with the "Throwable and Error classes should not be caught" rule, too... On Thu, Dec 4, 2014 at 1:44 AM, Aristedes Maniatis wrote: > I contacted the sonarqube people some weeks ago and they came back today > to tell me that our project is now updated to point to git. > > > http:

sonar code review

2014-12-04 Thread Aristedes Maniatis
I contacted the sonarqube people some weeks ago and they came back today to tell me that our project is now updated to point to git. http://nemo.sonarqube.org/dashboard/index/org.apache.cayenne:cayenne-parent As always, take the results with a grain of salt. However I do find that sometimes

Re: Sonar

2014-09-02 Thread Aristedes Maniatis
My passwords are also failing, including the one I used previously. I made a ticket for infra: https://issues.apache.org/jira/browse/INFRA-8301 Ari On 3/09/2014 8:33am, Michael Gentry wrote: > I found out we have a Sonarqube analysis set up: > > https://analysis.apache.org/dashboard/index/674

Sonar

2014-09-02 Thread Michael Gentry
I found out we have a Sonarqube analysis set up: https://analysis.apache.org/dashboard/index/67484 Apparently Ari did this a while back: https://issues.apache.org/jira/browse/INFRA-3789 However, it last ran in April and probably needs to be updated to pull from Git instead of SVN. Also, does a

Re: Sonar

2011-08-01 Thread Aristedes Maniatis
quals-and-hashcode-make.html I would suggest that Sonar actually has a very good point here, even though we may not hit problems often, it is certainly possible. Author advices to use URL.toString() as key instead. As for the false positives, I agree completely, obviously most of those ~10k de

Re: Sonar

2011-08-01 Thread Andrey Razumovsky
I've found this saying URLs are not good as keys for map/set (not performance issues though): http://alan.blog-city.com/do_not_use_javaneturl_as_a_key_in_hashmap.htm Author advices to use URL.toString() as key instead. As for the false positives, I agree completely, obviously most of those ~10k d

Re: Sonar

2011-08-01 Thread Michael Gentry
I'll have to look more later, but these tools often generate lots of false positives and need a way to silence warnings from run-to-run. mrg On Mon, Aug 1, 2011 at 8:42 AM, Andrus Adamchik wrote: > Depends on whether their assertion about DNS lookups is true. We are using > local URLs anyways,

Re: Sonar

2011-08-01 Thread Andrus Adamchik
Depends on whether their assertion about DNS lookups is true. We are using local URLs anyways, and nobody complained to date, but certainly worth a run in a debugger. On Aug 1, 2011, at 3:30 PM, Michael Gentry wrote: > Is this really a blocker? > > https://analysis.apache.org/drilldown/violati

Re: Sonar

2011-08-01 Thread Michael Gentry
Is this really a blocker? https://analysis.apache.org/drilldown/violations/org.apache.cayenne:cayenne-parent?priority=BLOCKER# Thanks, mrg On Mon, Aug 1, 2011 at 6:04 AM, Aristedes Maniatis wrote: > https://analysis.apache.org/dashboard/index/67484 > > We can certainly throw out all the findb

Re: Sonar

2011-08-01 Thread Andrus Adamchik
Cool. So how does it work? Is there a special Jenkins build for Sonar to collect this info? (Wonder what LCOM "Lack of Cohesion of Methods" measures?) Andrus On Aug 1, 2011, at 1:04 PM, Aristedes Maniatis wrote: > https://analysis.apache.org/dashboard/index/67484 > > We

Sonar

2011-08-01 Thread Aristedes Maniatis
https://analysis.apache.org/dashboard/index/67484 We can certainly throw out all the findbugs/clover/etc cruft now. This is much better. Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A