Re: [Geotools-devel] Thinking about static analysis

2018-12-27 Thread Andrea Aime
On Thu, Dec 27, 2018 at 6:46 PM Andrea Aime wrote: > I believe it was done once already in the past... think I did it actually, > it was running on a old computer below my desk > Ah yep, back in 2011: https://sourceforge.net/p/geotools/mailman/message/27433564/ Compare the enthusiasm in the thr

Re: [Geotools-devel] Thinking about static analysis

2018-12-27 Thread Andrea Aime
Hi Frank, I'm familiar with it and almost sure that while it can work in a job setting where one has hardening sprints and targets to get quality at certain levels, it won't work in an open source project like GeoTools or GeoServer, where each changeset is stand-alone, often driven by a particular

Re: [Geotools-devel] Thinking about static analysis

2018-12-27 Thread Frank Gasdorf via GeoTools-Devel
We are using https://www.sonarqube.org/ to check code quality not only for one project. Maybe it's worth to define rules that can be used by other OSGeo Projects as well. Great stuff IMHO, because you get trends, and coverage reports with maven builds, just integrate the plugin and configure Jenki

Re: [Geotools-devel] Thinking about static analysis

2018-12-26 Thread Andrea Aime
Hi Brad, looks like we overlapped a bit, I also took a stab at removing all un-necessary object wrapper constructions (including booleans). Sorry for not going public about that sooner! I've integrated your work and made a public branch here: https://github.com/geotools/geotools/tree/qa In privat

Re: [Geotools-devel] Thinking about static analysis

2018-12-26 Thread bradh
I sent a PR for the PMD branch that adds the ruleset as a local file. Because the ruleset has to be an absolute path to work in the PMD maven plugin, you now have to run at least the “initialize” goal in maven, something like: mvn initialize pmd:check -Ppmd I took the default ruleset and commen

Re: [Geotools-devel] Thinking about static analysis

2018-12-25 Thread Andrea Aime
On Mon, Dec 24, 2018 at 11:38 PM wrote: > +1: I’m always happy to have tools help me get things right. The other > tool I’ve seen, but not tried yet, is Infer (https://fbinfer.com/) > Interesting... the integration seems odd, there is an old/dead plugin, and the official way is to have infer run

Re: [Geotools-devel] Thinking about static analysis

2018-12-24 Thread bradh
+1: I’m always happy to have tools help me get things right. The other tool I’ve seen, but not tried yet, is Infer (https://fbinfer.com/) I had a look at the PMD branch, but it says “This branch is even with geotools:master.” – did you push? Brad _

Re: [Geotools-devel] Thinking about static analysis

2018-12-24 Thread Kurt Schwehr
I can help a little bit with fixing ErrorProne issues as I am already seeing them some with bazel builds On Mon, Dec 24, 2018 at 9:53 AM Ian Turton wrote: > Sounds good to me, I'm a little tied up just now, but I might be able to > help later. > > Ian > > On Mon, 24 Dec 2018, 15:38 Andrea Aime

Re: [Geotools-devel] Thinking about static analysis

2018-12-24 Thread Ian Turton
Sounds good to me, I'm a little tied up just now, but I might be able to help later. Ian On Mon, 24 Dec 2018, 15:38 Andrea Aime Hi all, > I was wondering if it might be time, and or it might be useful, to add > some static code analysis in our build > chain, as a profile that build servers can r

Re: [Geotools-devel] Thinking about static analysis

2018-12-24 Thread fernando.m...@geo-solutions.it
Cc Date Mon, 24 Dec 2018 16:37:57 +0100 Subject [Geotools-devel] Thinking about static analysis Hi all, I was wondering if it might be time, and or it might be useful, to add some static code analysis in our build chain, as a profile that build servers can run (especially Travis).