Some people have thought to change some of the default rules to match their standards. I prefer (so far) to create a "...Override.xml" file, and put it in my rulesets list before the default one. I'm hoping this "...Override.xml" file only needs to contain the rules that I'm overriding. I don't know whether this will work yet.
In the documentation, I see that it describes a "classpath" element in the "pmd" element. However, when I run the task using this, it says 'The <pmd> task doesn't support the nested "classpath" element.'
I'm using PMD 1.05. Is the documentation out-of-date? How can you specify a particular directory to read additional rulesets from?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can specify a particular directory by putting it on the classpath and then specifying individual ruleset.xml files that are in that directory. So if c:\foo is on the classpath, your Ant target can use rulesetfiles="myrules.xml" if myrules.xml is in that directory.
Or you can use a full path to a particular ruleset - like this: rulesetfiles="c:\foo\myrules.xml". Either way will work....
My problem is that I don't want to have external CLASSPATH entries. I want the entire build specification to be in my build.xml file. Therefore, I want to use a nested "classpath" entry, or whatever facility is available in the "pmd" task for specifying other places to look for ruleset files.
The "ant-task.html" page describes a nested "classpath" entry, but when I try to use it, I get an error like 'the <pmd> task doesn't support the nested "classpath" element.'
The other aspect that I don't see described anywhere is what happens if you try to override rulesets, or individual rules, with ruleset files earlier in the classpath. In my case, I've made a copy of "naming.xml" and named it "namingOverride.xml", and I've reduced the file to only the rules I want to override. I haven't been able to see if this works, as I can't get around the nested classpath problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, that appeared to fix that problem. When will this be in a new release?
However, related to this problem, I also see that the "verbose" attribute is not supported. I wanted to turn on "verbose" because when PMD tries to process either of two particular (very simple) source files, it emits a message "Error while processing ...", with no other information. This occurs even in the new release I got from you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One thing that is mentioned in the obsolete documentation for the "verbose" attribute is that it says it will show full stacktraces. That might have been useful now.
All I get on these two source files is the following error message (replaced file path with "..."):
net.sourceforge.pmd.PMDException: Error while processing ...
There is no other information. I do get other normal processing on these files (PMD found a couple of minor issues in the code), and it processes other source files without giving that error message.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My "test.pmd" task has "compile" as a dependency, so the code definitely compiles. I'm not using "assert" anywhere (in any way), either. Both of these classes are just simple bean classes (Serializable with simple getters/setters).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I thought I made this clear by implication, but I'm using all of the default built-in rulesets, along with one custom one. The following is the list that I'm using in the "pmd" tag:
Ah, OK, I see the problem. Try removing the experimental.xml ruleset and the newrules.xml ruleset. Those are just for testing and such - they aren't meant to be run in practice. They contain rules that may bail out on perfectly valid Java code.
The obvious question is - then why are they in the jar file? The answer is - they won't be in future releases :-)
Yours,
Tom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also, FWIW, I think you'll find that picking and choosing a couple of rules will work better than running every ruleset.
For example, the controversial ruleset contains one rule that checks to see that every class has a constructor, and another rule that checks to if a class has an unnecessary constructor - i.e., a no-arg constructor with nothing inside it. So if you include all the rules from controversial.xml, you'll always get some rule violations no matter what you do :-)
Yours,
Tom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, removing those three rulesets made the errors go away. However, note that my problem is not that I'm getting standard PMD violations, but that I'm getting an unspecified "error" from two classes (although I also get normal PMD violations). The value of the rules specified in those rulesets that I removed may be questionable, but it appears that the implementation of those rules triggers some sort of problem in PMD. I'm willing to go with this, but if you want more information about what was really failing in PMD, I'm willing to try another release that can give you more information (if you build it, that is).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your willingness to help debug - if the problems are only occurring when you use experimental.xml and newrules.xml, that's expected - those are still works in progress.
If the errors occur when you run any of the other rulesets, though, that's definitely a problem of some sort and I'd welcome any more information about them....
Thanks,
Tom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some people have thought to change some of the default rules to match their standards. I prefer (so far) to create a "...Override.xml" file, and put it in my rulesets list before the default one. I'm hoping this "...Override.xml" file only needs to contain the rules that I'm overriding. I don't know whether this will work yet.
In the documentation, I see that it describes a "classpath" element in the "pmd" element. However, when I run the task using this, it says 'The <pmd> task doesn't support the nested "classpath" element.'
I'm using PMD 1.05. Is the documentation out-of-date? How can you specify a particular directory to read additional rulesets from?
Hi David -
You can specify a particular directory by putting it on the classpath and then specifying individual ruleset.xml files that are in that directory. So if c:\foo is on the classpath, your Ant target can use rulesetfiles="myrules.xml" if myrules.xml is in that directory.
Or you can use a full path to a particular ruleset - like this: rulesetfiles="c:\foo\myrules.xml". Either way will work....
Does that explain things better? Am I answering the question? Actually... how can we improve the documentation here - http://pmd.sourceforge.net/howtomakearuleset.html - to make this more clear?
Thanks,
Tom
My problem is that I don't want to have external CLASSPATH entries. I want the entire build specification to be in my build.xml file. Therefore, I want to use a nested "classpath" entry, or whatever facility is available in the "pmd" task for specifying other places to look for ruleset files.
The "ant-task.html" page describes a nested "classpath" entry, but when I try to use it, I get an error like 'the <pmd> task doesn't support the nested "classpath" element.'
The other aspect that I don't see described anywhere is what happens if you try to override rulesets, or individual rules, with ruleset files earlier in the classpath. In my case, I've made a copy of "naming.xml" and named it "namingOverride.xml", and I've reduced the file to only the rules I want to override. I haven't been able to see if this works, as I can't get around the nested classpath problem.
Ah, OK. There was a bug in the pmd-1.05 release that prevented the nested classpath stuff from working. You can download an updated version here:
http://infoether.com/~tom/pmd-1.05.jar
That should fix it...
Yours,
Tom
Ok, that appeared to fix that problem. When will this be in a new release?
However, related to this problem, I also see that the "verbose" attribute is not supported. I wanted to turn on "verbose" because when PMD tries to process either of two particular (very simple) source files, it emits a message "Error while processing ...", with no other information. This occurs even in the new release I got from you.
Right, now you can get "verbose" behaviour using the ant verbose flag, i.e.:
ant -verbose pmd
Yours,
Tom
One thing that is mentioned in the obsolete documentation for the "verbose" attribute is that it says it will show full stacktraces. That might have been useful now.
All I get on these two source files is the following error message (replaced file path with "..."):
net.sourceforge.pmd.PMDException: Error while processing ...
There is no other information. I do get other normal processing on these files (PMD found a couple of minor issues in the code), and it processes other source files without giving that error message.
> "verbose" attribute is that it says it will
> show full stacktraces.
Hm, I'll look into that, thanks for the report.
> Error while processing ...
Could be happening if the code is either uncompilable or is using "assert" as a non-keyword. I'll look into getting those stacktraces working...
Thanks,
Tom
My "test.pmd" task has "compile" as a dependency, so the code definitely compiles. I'm not using "assert" anywhere (in any way), either. Both of these classes are just simple bean classes (Serializable with simple getters/setters).
Hm. Are you using just the built-in rulesets or some custom rulesets?
Thanks,
Tom
I thought I made this clear by implication, but I'm using all of the default built-in rulesets, along with one custom one. The following is the list that I'm using in the "pmd" tag:
pmd.rulesets = \ rulesets/namingOverride.xml,\ rulesets/coupling.xml,\ rulesets/design.xml,\ rulesets/controversial.xml,\ rulesets/newrules.xml,\ rulesets/junit.xml,\ rulesets/strings.xml,\ rulesets/unusedcode.xml,\ rulesets/naming.xml,\ rulesets/imports.xml,\ rulesets/basic.xml,\ rulesets/favorites.xml,\ rulesets/experimental.xml,\ rulesets/codesize.xml,\ rulesets/braces.xml
Ah, OK, I see the problem. Try removing the experimental.xml ruleset and the newrules.xml ruleset. Those are just for testing and such - they aren't meant to be run in practice. They contain rules that may bail out on perfectly valid Java code.
The obvious question is - then why are they in the jar file? The answer is - they won't be in future releases :-)
Yours,
Tom
Also, FWIW, I think you'll find that picking and choosing a couple of rules will work better than running every ruleset.
For example, the controversial ruleset contains one rule that checks to see that every class has a constructor, and another rule that checks to if a class has an unnecessary constructor - i.e., a no-arg constructor with nothing inside it. So if you include all the rules from controversial.xml, you'll always get some rule violations no matter what you do :-)
Yours,
Tom
Ok, removing those three rulesets made the errors go away. However, note that my problem is not that I'm getting standard PMD violations, but that I'm getting an unspecified "error" from two classes (although I also get normal PMD violations). The value of the rules specified in those rulesets that I removed may be questionable, but it appears that the implementation of those rules triggers some sort of problem in PMD. I'm willing to go with this, but if you want more information about what was really failing in PMD, I'm willing to try another release that can give you more information (if you build it, that is).
Hi David -
Thanks for your willingness to help debug - if the problems are only occurring when you use experimental.xml and newrules.xml, that's expected - those are still works in progress.
If the errors occur when you run any of the other rulesets, though, that's definitely a problem of some sort and I'd welcome any more information about them....
Thanks,
Tom