5:59 p.m.
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?
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(a)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(a)infinispan.org>
> To: "infinispan -Dev List" <infinispan-dev(a)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(a)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/841c789a866745b8d48475f98ac...
> >> [3]
> >>
https://github.com/infinispan/infinispan/blob/841c789a866745b8d48475f98ac...
> >> [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(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev