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
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 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. 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