On Aug 23, 2009, at 3:36 AM, Adam Murdoch wrote:
Hans Dockter wrote:
On Jul 21, 2009, at 6:43 AM, 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.
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.
With checkstyle you pretty often need additional configuration
files. So may be $projectDir/config/checkstyle/checkstyle.xml might
be a better choice. We might do it the same for codenarc. If more
and more plugins need
configuration files we might need to come up with some additional
structure.
I think this make sense. I will change the default to config/
$toolName/$configFileName
- Should we provide some default configuration for these tools?
Maybe some named configuration sets?
Our future archetype plugin could either create empty templates or
optionally preconfigured xml files.
I'm not that keen on solutions which rely on an archetype plugin
being used. An archetype plugin feels to me like a work-around for
over-complex initial setup. I think it would be much better if we
choose good defaults and have sensible behaviour when things are not
present.
I agree. The advantage of such templates is that they could offer a
very helpful start for doing custom configurations. That would not be
needed I we have a DSL for code quality in the future.
- Should it be possible to ignore violations?
I think so.
(and why?)
Because some users want it :)
And why do they want it? I want to figure out if we need a
consistent model for handling violations, and what that might be. I
don't want to expose something that is different per-tool.
I see.
One important use case for not letting the build fail is, if this is
not accepted by all members of the team. The might be projects were
some people care more than others and the others don't have a standing
to make a strong policy. They still want to get informed if things are
not in shape and might even be the cleaner. It is not the project I
would like to work in but I know they exists.
Beside this I don't know a strong reason why you don't want to let the
build fail if policies are violated.
We have a few options:
1. Nothing other than what the tool provides via it's config file
(eg checkstyle suppressions file)
2. An ignoreViolations flag on the task
3. A maxViolations property on the task
But they can disable this behavior already by setting the
appropriate properties, can't they.
Not yet. The Checkstyle and Codenarc tasks don't have any settings
which let you control this.
As I understand the code, the Checkstyle.properties property is
applied against the Ant checkstyle task. So a Gradle user could for
example set the properties failOnViolation, maxErrors and maxWarnings
of the Ant checkstyle task. Am I missing something?
We might expose this properties explicitly by our own API.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
