Groovy and Grails are a breeze of fresh air in Java development and Web application development as they enable you to write far more expressive and readable code. They also solve most of the classic Java pitfalls (BigDecimal, equals(), etc…) all new Java programmers meet along their way. Even if you write more readable and thus more maintainable code in Groovy, this is not enough let alone: of course you need some good practices to keep your code under control as your application keeps growing.
One of these practices would be to analyze your source code and check how metrics and static checks evolve from release to release, or even on a more sporadic way for a specific release. In this field I must say that the Java programmer is one of the best tooled as there are plenty of choices, free or not, for performing such a task (PMD, FindBugs, CheckStyle, Sonar etc…). So, what about it in Groovy / Grails?
Groovy eco-system is far smaller than in Java when talking about code analysis tools. Basically you will find:
Can they work or not on Groovy code? Of course we haven't tried all of them but basically you will find two categories of tools:
So all those tools are of little help for what we are looking for!
As Java programmers, we hope to find in Groovy / Grails eco-system the same tools we are used to in Java. What a shame there isn't a FindBugs for Groovy! But does it make sense?
Groovy is by nature a dynamic language and of course you don't develop code in the same way you develop it with a static language. Groovy is both weakly and strongly typed, as you wish, but is very often used with weak typing (I think I should say duck typing actually, see here). Of course there is a strong emphasis on tests in dynamic languages if you want your software to be both reliable and maintainable. But as mentalities evolve, I would say this is no more a difference between static and dynamic languages given tests have taken such an importance as well for static languages. We no longer ensure code quality afterwards by running analysis tools but we do ensure it beforehand by testing in TDD.
To make a long story short, I would say that the code coverage is thus one of the most important metric to watch, more than all the metrics and potential bugs that these tools can compute. Good news, there is a code coverage plugin for Grails which is called Test Code Coverage Plugin. It uses Cobertura underneath as Cobertura has a support for the Groovy language (Clover too).
To make my short story even shorter: we won't necessarily miss all these analysis tools we have in Java.
Of course the usefulness of all these tools is highly context-dependent and you might be in a context where you will truly miss one of these tools. For example I would truly miss Checkstyle, Findbugs and PMD in a project with several team members and different skill levels. Or I would truly miss XDepend in a big project where project architecture has been lost or is undefined. No doubt the support for Groovy in this kind of tools will grow if Groovy / Grails make their way in the enterprise or continue to spread in the small to mid-size projects where they are currently used. As usage will increase, anti-patterns will become clearer and enable this kind of tools to become more useful.
Sonar looks like the perfect fit for the job even if the plugin is still in its early stage. Note, if you are already using a Hudson or plan to setup one, you could setup most of the above tools (CodeNarc, CPD, Cobertura etc...) in your Hudson.
Actually, even if Sonar is really easy to install, analyzing a Grails project with it is a little bit trickier.
Here is how to proceed:
Basically you just have to download Sonar and unzip it wherever you want. Then you download Groovy plugin for Sonar and you copy the downloaded JAR in [sonar]/extensions/plugins where [sonar] is the directory where you extracted Sonar ZIP file.
At last you run Sonar server, using sonar.sh or StartSonar.bat depending on you platform. For more info, see their 2-minutes tutorial.
A good starting point is the plugin home page. It is only valid for a Groovy project, setting up a Grails project is slightly different.
You have basically two choices:
This is, interestingly, my recommended approach. Actually this is the one that works best at this time. For this you need;
$ grails install-plugin code-coverage- to configure Cobertura to generate the XML report needed by Sonar. For this, add these lines to your grails-app/conf/BuildConfig.groovy file:coverage {
enabledByDefault = false
xml = true
}
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.yourcompany</groupId>
<artifactId>yourproject</artifactId>
<version>1.0</version>
<packaging>pom</packaging>
<name>Your Project</name>
<build>
<sourceDirectory>grails-app</sourceDirectory>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.6</source>
<target>1.6</target>
<excludes>
<exclude>**/*.*</exclude>
</excludes>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>src/groovy</source>
<source>src/java</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<properties>
<sonar.language>grvy</sonar.language>
<sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
<sonar.surefire.reportsPath>test/reports</sonar.surefire.reportsPath>
<sonar.cobertura.reportPath>test/reports/cobertura/coverage.xml</sonar.cobertura.reportPath>
<sonar.phase>generate-sources</sonar.phase>
</properties>
</project>
$ grails test-app -coverageThis setup is easier but, at the time of writing it out, you will get a few limitations. This is what you need to add in your POM:
<properties>
<sonar.language>grvy</sonar.language>
</properties>
<build>
<sourceDirectory>grails-app</sourceDirectory>
</build>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.6</version>
<configuration>
<reportsDirectory>${project.build.directory}/test-reports</reportsDirectory>
</configuration>
</plugin>
</plugins>
</build>
This is it!
You just need to run the following command at the root of your Grails project (make sure Sonar is running, refer to Step 1): $ mvn sonar:sonar
Then go to Sonar web interface by browsing to http://localhost:9000/ and enjoy it!
You will get the standard Sonar dashboard you are certainly used to:
Be aware you will have to configure CodeNarc and CPD to only report warnings and errors you really want your team to fix. This is the hardest part in setting up this kind of tools on a project.
The plugin has a few limitations, the greatest one being the problem in parsing some Groovy files (see SONARPLUGINS-596). It has obviously an impact on the report because the figures, violations and duplications will completely ignore the files in error. It will be interesting for you to see which files are impacted by looking at the stack traces when running 'mvn sonar:sonar'.
Otherwise, if you use Maven, you get a few more limitations: - Sonar Groovy plugin only locates your source files by the use of the sourceDirectory parameter therefore with the above setting (set to grails-app/), files in src/groovy and src/java won't be included in the analysis results (see SONARPLUGINS-737) - the analysis won't work if one of your tests is failing (unfortunately Grails Maven plugin ignores the parameter -Dmaven.test.failure.ignore=true, see GRAILS-6850)
There is one last point about source code quality we did not mentioned at all in this article, which is the IDE. Of course the IDE is of great help to manage source quality at the root by the use of JavaDoc, code completion and refactoring, but also through the use of all sort of plugins (often the same tools as mentioned above). The same is true in Groovy and using a good IDE is certainly a productivity and quality boost. You will even find in IntelliJ IDEA checks on what is call 'idiomatic Groovy' - or Groovy code inspections. This is a broad subject and would be for sure an interesting subject to dig further in another article.
But here also, you could ask yourself are you really looking for the right tool? You will see plenty of Grails or Ruby on Rails developers going back to the use of a clever text editor like TextMate instead of the big IDE we are used in Java. In fact I am not sure they are wrong, depending of course on the size of the project they are presently working on...