Russel Winder wrote:
Adam,
On Tue, 2009-07-21 at 14:43 +1000, Adam Murdoch wrote:
Hi,
I've just checked in a 'code-quality' plugin, which currently adds
Checkstyle and CodeNarc tasks to Java and Groovy projects, respectively.
My plan is that this plugin would later also add support for tools such
as cobertura, PMD, and so on.
So should I stop working on a separate Cobertura plugin and just create
a patch for this to add Cobertura support?
Probably not. I imagine what we'll do at some point is split checkstyle
and codenarc plugins out, and leave the code-quality plugin to just wire
everything together (and maybe adds some integrated reporting, or
standard checks, or something).
Should Emma be added to the
list.
Probably.
I am assuming in the end Gradle will support all the reporting tools
that Maven does.
I think so.
I have some questions about which conventions this plugin should follow.
I've just made some stuff up, based on what I've done on various
projects, but I have no idea if they are conventions or not. Please let
me know if you have an opinion on these:
- Where should the config files for these tools live? Currently, the
plugin expected to find them at $projectDir/config/checkstyle.xml and
$projectDir/config/codenarc.xml.
As with any and all configuration files, I would have:
-- per project (as above)
-- per user (in ~/.gradle/config)
-- per computer (in $GRADLE_HOME/config and /etc/gradle/config)
Do we have to use XML, why can't we use Groovy for configuration?
Because these are the configuration files for the tools themselves, both
of which have decided to use XML as their config file format. I really
don't want to invent (and document) a groovy based format for these.
Having said that, I reckon it would be fantastic to have a code quality
DSL in groovy, which would describe high level constraints, independent
of the actual tools. Then, the config files for the individual tools
could get generated from this description.
- Should we provide some default configuration for these tools? Maybe
some named configuration sets?
- Where should the results go? Currently, they end up in
$buildDir/checkstyle/main.xml, $buildDir/checkstyle/test.xml,
$buildDir/reports/codenarc/main.html, and
$buildDir/reports/codenarc/test.html (there's no checkstyle report, yet,
just a results xml file).
- Should it be possible to ignore violations? (and why?)
Pass on these as I am not sure.