Hans Dockter wrote:
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.
Doesn't sound like something we want to encourage. For this use case,
something simple like an ignoreViolations flag would probably do.
One possible use case for a maxViolations option would be where you have
an existing codebase and you are switching on the rules one at a time,
like in the Gradle build. You could use a workflow something like:
- switch on the check
- set maxViolations to the number of current violations
- check in
- over time, reduce maxViolations to 0.
- repeat for the next check.
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?
I don't think they are. These properties are passed through to
checkstyle, which substitutes them into the config file.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
