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.

Reply via email to