[infinispan-dev] FindBugs on infinispan

Fri Mar 20 13:46:31 EDT 2015

Hey Dan,

> Keeping off the thread topic for a bit: I'm all for using a standard
> formatting and enforcing that on commit, but I don't see how that
> would make it easy for people to use their preferred code style in
> their IDEs. Would they reformat everything so it's easier for them to
> read, and never ever use git diff or annotate? Or would they use their
> preferred code style just in the lines they modify, just to prove to
> themselves that their style is better and ignoring the fact that the
> mix of styles makes it much harder to read?

On your off topic thread question: My thought was that you could reformat the code to whatever style you like in your IDE while you are working on it locally, but you make a valid point about the fact that doing comparisons to upstream will be difficult. I guess you would still need a way to reset the format to upstream in this case which means this doesn't solve much. I guess the current strategy of trying to keep the IDE formatting preferences in-sync is still the best right now.

Thanks,
Alan

> Back on topic: TC also allows you to produce custom metrics for a
> build and put them in a chart, or fail the build if the value of the
> metric increases too much (like we have now for the test duration). It
> does sound interesting, but I'm not sure where you guys got the idea
> that a failed build will prevent a PR from being integrated ;)
> 
> Cheers
> Dan
> 
> 
> On Fri, Mar 20, 2015 at 3:03 PM, Alan Field <afield at redhat.com> wrote:
> > I really like the idea of "forcing a trend of improvement"! :-) I agree
> > with Radim that getting the improvement in the code is the hard part.
> > Running static analysis tools on the files you are modifying is a great
> > way to tackle the problem in a manageable fashion. Looking at all of the
> > output across a project is daunting! I've also always thought source code
> > formatting arguments were a waste of time, so I have always thought that
> > the source code should be formatted by a tool when checked into the repo.
> > That way individuals can apply whatever formatting they prefer in their
> > IDEs, but the source code in the repo is stored in a specific way.
> >
> > Thanks,
> > Alan
> >
> > ----- Original Message -----
> >> From: "Sanne Grinovero" <sanne at infinispan.org>
> >> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
> >> Sent: Friday, March 20, 2015 7:57:14 AM
> >> Subject: Re: [infinispan-dev] FindBugs on infinispan
> >>
> >> Same for Eclipse. I run it occasionally, but only the modules I'm working
> >> on.
> >> If everyone could do the same, that helps ;-)
> >>
> >> There is an option to get Maven to fail the build on specific
> >> selectable categories; I've played with that in the past but I had the
> >> impression that the annoyance level and maintenance overhead was a bit
> >> too high compared to the benefits.
> >>
> >> With Jenkins you can plot graphs, to make sure you have a general
> >> trend of such problems to get lower over time.. and if I remember
> >> correctly there also should be a way to have it reject a PR if the
> >> threshold of code quality degradation is too high.
> >> We do the same for CheckStyle on Hibernate ORM: not forcing an
> >> absolute zero of violations (there's too much to fix!) but forcing a
> >> trend of improvement.
> >>
> >> See: http://ci.hibernate.org/view/ORM/job/hibernate-orm-4.3-h2/
> >>
> >> -- Sanne
> >>
> >> On 20 March 2015 at 11:39, Pedro Ruivo <pedro at infinispan.org> wrote:
> >> > Hi,
> >> >
> >> > There is a findbugs pluging for IntelliJ.
> >> >
> >> > I run it against the classes I modified in the PR and solve the existing
> >> > problems and avoid creating new ones.
> >> >
> >> > Pedro
> >> >
> >> > On 03/19/2015 04:16 PM, Jakub Markos wrote:
> >> >> Hi,
> >> >>
> >> >> out of curiosity, I ran FindBugs [1] (java static analysis tool) on
> >> >> infinispan. Attached are 2 output files (compressed, because the
> >> >> mailing
> >> >> list accepts only <0.5MB attachments):
> >> >> 1. for the release-jars-analysis.html, only the 3 main jars from
> >> >> 7.2.0.Alpha1 were analyzed
> >> >> 2. for the project-jars-analysis.html, I took all jars that were
> >> >> present
> >> >> in the infinispan project directory after a build (except the test
> >> >> jars)
> >> >> - this one has therefore more findings
> >> >>
> >> >> In both cases, FindBugs complained that it couldn't find some imported
> >> >> classes, so the analysis may not be 100% complete.
> >> >>
> >> >> I didn't look through the actual results much, but for example it
> >> >> detected
> >> >> an infinite loop at [2], or a self-assignment at [3].
> >> >>
> >> >> If you want to run it yourself, you can use [4]. There is also a GUI,
> >> >> but
> >> >> I wasn't able to save the results into a html, and a maven
> >> >> plugin [5], but it only creates the results in an xml format for each
> >> >> module separately, so it's not very useful.
> >> >>
> >> >> Jakub
> >> >>
> >> >> [1] http://findbugs.sourceforge.net/
> >> >> [2]
> >> >> https://github.com/infinispan/infinispan/blob/841c789a866745b8d48475f98acd51fa74b16f13/core/src/main/java/org/infinispan/context/impl/ImmutableContext.java#L95
> >> >> [3]
> >> >> https://github.com/infinispan/infinispan/blob/841c789a866745b8d48475f98acd51fa74b16f13/client/hotrod-client/src/main/java/org/infinispan/client/hotrod/impl/transport/tcp/TcpTransportFactory.java#L90
> >> >> [4] bin/findbugs -maxHeap 4000 -effort:max -textui -progress -release
> >> >> infinispan -html -output infinispan-findbugs-analysis -onlyAnalyze
> >> >> org.infinispan.-
> >> >> infinispan-7.2.0.Alpha1-all/infinispan-embedded-7.2.0.Alpha1.jar
> >> >> infinispan-7.2.0.Alpha1-all/infinispan-embedded-query-7.2.0.Alpha1.jar
> >> >> infinispan-7.2.0.Alpha1-all/infinispan-remote-7.2.0.Alpha1.jar
> >> >> [5] http://mojo.codehaus.org/findbugs-maven-plugin/
> >> >>
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> infinispan-dev mailing list
> >> >> infinispan-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> >>
> >> > _______________________________________________
> >> > infinispan-dev mailing list
> >> > infinispan-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 