Hi, Le 12 sept. 2014 19:11, "[email protected]" <[email protected]> a écrit : > > > > On 12 Sep 2014 at 19:02:38, Sergiu Dumitriu ([email protected](mailto: [email protected])) wrote: > > > On 09/12/2014 12:52 PM, [email protected] wrote: > > > > > > On 12 Sep 2014 at 18:46:33, Sergiu Dumitriu > > > ([email protected](mailto:[email protected])) wrote: > > > > > >> A tool still being maintained and released isn't dead. The fact that > > >> there's healthy competition is good, not bad, for a project. And we're > > >> not bound to using the most complex tool available, we should use the > > >> one which works best for us, where "best" should be agreed on by the > > >> community. > > >> > > >> There should be a separate vote about switching from Checkstyle to > > >> Sonar. If you send such a vote, we can put this on hold until we decide > > >> one way or the other. > > >> > > >> It's kind of backwards to agree on the rules before agreeing on the tool > > >> first. > > > > > > The decisions are separate: we’re already using Sonar and we’ve never > > > really taken the time to define the rules we wish applied there on > > > http://sonar.xwiki.org > > > > > > So there are several related but orthogonal decisions: > > > 1) Define the sonar rules for the web site > > > 2) Decide if we wish to automatically fail the build when a sonar rule > > > fails. Basically this means deciding to use sonar as THE one tool for > > > rule checking. An alternative would be to use the Maven Findbugs plugin, > > > Maven PMD plugin, etc. But it would be a lot less powerful than Sonar. > > > For example in Sonar you can combine the rules and say things like “fail > > > the build if such rule and such rule fail or if the TPC is below that > > > value or …”. > > > > > > Now since Sonar also contains the checkstyle rule in the end we will > > > need to decide which checkstyle rules we wish to use too, so this work > > > has to be done anyway. It’s just not the only one since there are more > > > rules (and a lot more interesting than the checkstyle ones, in other tools). > > > > > > > Two question I have about Sonar: > > > > 1. Can it fail the build when I run mvn install locally? I don't want to > > have to wait hours to find out if I have all the spaces in order. > > You need to have sonar.xwiki.org up. AFAIU you execute mvn sonar:sonar and if you have installed this sonar plugin it’ll fail the build: http://docs.codehaus.org/display/SONAR/Build+Breaker+Plugin
But you can't build offline and get your checks executed anymore, as it will always fail to reach sonar. > > > If it's only an online asynchronous tool, we'll get in the same > > situation as with our CI failures, we'll pay attention to failures for a > > few weeks, then most devs will give up and check the build status only > > when pinged or when it's a BuildFixingDay. > > Yes I agree. > > > 2. Does it run faster or slower than the Checkstyle plugin? If slower, > > by how much? The build already takes too much time for devs to have the > > patients to build more than one submodule before committing, we don't > > want devs to skip running checks locally completely. > > I think the problem is that sonar:sonar will run a ton of other things That added to network latencies for pushing the metrics to sonar added to the fact that you need access to sonar database, not only http (from your computer I mean), which can be a problem for spread teams. so we need to verify if we can find a way to have several execution paths: > - one path for developers when they want to quickly check locally if their code that they want to push have any violations. Note to self: verify if this can work on uncommitted code. > - another path for the CI, that executes less often to generate the full sonar.xwiki.org dashboard with TPC computations and more > > TBH I don’t know how well this will work out at this point. We need to try it out for real and see how it works. Basically sonar only aggregates and consolidates other plugins rules, and adds some in the process. Personally I find it great for daily dashboards, readable even by not-so-technical people, but for failfast builds it's a bit heavy unless you have a performant infrastructure. I use it only in nightly builds and for releases, for failing the build I configured the same rules in checkstyle, pmd and findbugs. Rulesets can be exported from sonar, but with some rework for findbugs. That being said, the 3 plugins alone are not so fast either... :D and findbugs is great but their maven plugin... > > Now we could imagine: > - having simple fast rules in our build that execute locally > - having more complex rules (like TPC% less than previous values) that run on CI only > > Thanks > -Vincent > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
