Hi,
I'm new to PMD and am investigating it to use it in our development process...
Our requirement is to be able to have PMD ignore a method or a class or a file while checking for a voilation... We want to make certain voilations in certain places and not everywhere...
Is that something I can implement?
thnx
_Faheem
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would suggest the inclusion of a pair of regex expressions that can be used to filter out classes and methods. These optional command-line args could then be used to filter out whole packages one might not have control over or generated code that can't be modified.
I just can't see myself tagging umpteen individual classes and methods with //NOPMD tags.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Faheem
Just my 2 cents here regarding performance. I've checked in 1 rule which had a horrendous performance footprint (15 minutes over 7,000 files), that is UselessOperationOnImmutable. I'm working slowly at improving the performance of other rules - I'll probrably check in OverrideBothEqualsAndHashcode tonight.
If you run Benchmark, as Tom suggested above, it will tell you what rules are consuming the most amount of time. With 130 rules running, that's probrably your best place to start.
One other thought is how you're deploying the rules. In my experience, it's easier to roll out rules in groups, mitigating each rollout to allow an easy-to-manage number of issues to resolve. I found rolling out a couple rules and saying "OK guys, 100 issues to solve" worked a lot better than saying "10,000 issues to solve".
Another thought is it's possible that if you're getting a lot of violations that you are hitting some memory problems (I haven't tried to profile a large codebase with a large number of rules turned on, however).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm having a similar issue with the Eclipse plugin in WSAD. We've approximately 6,000 Java files in our Workspace at the moment. Some of these are generated files, both our own and those created by WSAD (EJB stubs).
I've been unable to find a means to exclude these these generated files from PMD's scrutiny.
The other major issue I'm encountering is the sheer time it takes for these rules to be applied. I gave up after a full rebuild of my workspace took over 4+ hours.
I was really looking forward to bring PMD into our development environment (now is the ideal opportunity in our schedule). But, it's just not practical. At this point, I've pushed out empty rulesets to everyone, until I can figure these issues out.
We're not prepared to use PMD only in a build environment at this time. Immediate feedback in an IDE is much preferred.
I'll spent some personal time to see if I can work this out. I'll submit a patch if I do.
Thanks,
Ryan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the Eclipse plugin, you have to build a working set (look in the PMD config in the project) that includes the packages you care about, and doesn't include the generated code packages.
Gee, your full rebuild took ONLY 4 hours? I have a project with 7500 source files, and a working set of only 935 files took about 13 hours.
Fortunately, my input on this problem was helpful to the plugin author, who will be releasing a new version Real Soon Now (after/combined with Tom releasing PMD 3.7) that should be a big help for this problem. I don't yet know how much it will help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Um, working sets sounds like a nice PITA on 16 projects and 100s of packages. :) No thanks, I'll hack PMD to have a simple regex filter on file names specified in the ruleset files before I push that onto my developers. Then at least we'll be able to manage it centrally and uniformly.
I'm most concerned about the speed at this time. It's just insanely slow. My initial examinations make me think it's an issue with the overhead of the sheer number of Iterator instances produced by the DocumentNavigator for Jaxen. I'm gonna have to play around some and see what I can find.
Ryan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hm... I'd be suprised if Jaxen were the bottleneck... I mean, what happens if you run PMD on your code from the command line? Try running it from the command line with the -debug flag and see how it goes; it should be pretty snappy:
./pmd.sh /path/to/your/src/ text unusedcode -debug
I ran the ruleset you provided on the code in my workspace from the command line and it took just under 3 minutes. Which is rather quite nice, considering all the file parsing and etc.
Now, when I ran a ruleset containing the rules we would like to use (some 130 rules imported from the various OOTB PMD rules, no custom rules), it took about 90 minutes.
I infer two things from this:
1) There's definately something going on in the Eclipse environment to slow things down over what pure PMD is capable of doing.
2) Either because of the number of rules, or because of certain non-performant rules, PMD isn't scaling up very nicely with our particular ruleset.
I'd ideally like the PMD checks to take no more than 15 minutes. A full rebuild of our Eclipse workspace already takes 15 minutes, during which folks usually just do something else. I think I can justify the additional time given what PMD can do for our code quality.
I'll investigate our ruleset imports and see what I can find in the eclipse plugin. I'll work on our rule applicability to files problem after I get performance figured out.
Thanks,
Ryan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> it took about 90 minutes.
> [...] or because of certain non-performant rules
Hehe, yup, a bit longer. There's a benchmarking utility that comes with PMD that you can use to see which rules are the slowest; it's net.sourceforge.pmd.util.Benchmark:
If you want, give that a whirl on one or two files and let me know which rules you are using that are taking the longest. Maybe there's some low-hanging fruit for optimization there. And of course all the other PMD users would benefit as well, which is nice...
thnx folks... this discussion has been helpful...
i'm planning to implement PMD plugin for eclipse for our development team.. the # of files right now is small (a few hundreds), but it will grow over time in the next 6-10months to a few thousands. IF there are ANY optimizations done to the plugin to make it faster, how do I get to know about it?
thnx
-Faheem
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm new to PMD and am investigating it to use it in our development process...
Our requirement is to be able to have PMD ignore a method or a class or a file while checking for a voilation... We want to make certain voilations in certain places and not everywhere...
Is that something I can implement?
thnx
_Faheem
I would suggest the inclusion of a pair of regex expressions that can be used to filter out classes and methods. These optional command-line args could then be used to filter out whole packages one might not have control over or generated code that can't be modified.
I just can't see myself tagging umpteen individual classes and methods with //NOPMD tags.
That's kind of the nice thing about the annotation excluders, though - they can work on an entire class or method. Of course, they are JDK 1.5-only...
Yours,
Tom
Faheem
Just my 2 cents here regarding performance. I've checked in 1 rule which had a horrendous performance footprint (15 minutes over 7,000 files), that is UselessOperationOnImmutable. I'm working slowly at improving the performance of other rules - I'll probrably check in OverrideBothEqualsAndHashcode tonight.
If you run Benchmark, as Tom suggested above, it will tell you what rules are consuming the most amount of time. With 130 rules running, that's probrably your best place to start.
One other thought is how you're deploying the rules. In my experience, it's easier to roll out rules in groups, mitigating each rollout to allow an easy-to-manage number of issues to resolve. I found rolling out a couple rules and saying "OK guys, 100 issues to solve" worked a lot better than saying "10,000 issues to solve".
Another thought is it's possible that if you're getting a lot of violations that you are hitting some memory problems (I haven't tried to profile a large codebase with a large number of rules turned on, however).
Hi Faheem -
Hm. If you're using JDK 1.5, you can do this using a class or method level annotation:
http://pmd.sourceforge.net/suppressing.html
If you're on JDK 1.4 or lower, your best bet might be to exclude the file from the PMD scan using an Ant exclude element or some such.
Yours,
Tom
Using PMD? Get the book! http://pmdapplied.com/
I'm having a similar issue with the Eclipse plugin in WSAD. We've approximately 6,000 Java files in our Workspace at the moment. Some of these are generated files, both our own and those created by WSAD (EJB stubs).
I've been unable to find a means to exclude these these generated files from PMD's scrutiny.
The other major issue I'm encountering is the sheer time it takes for these rules to be applied. I gave up after a full rebuild of my workspace took over 4+ hours.
I was really looking forward to bring PMD into our development environment (now is the ideal opportunity in our schedule). But, it's just not practical. At this point, I've pushed out empty rulesets to everyone, until I can figure these issues out.
We're not prepared to use PMD only in a build environment at this time. Immediate feedback in an IDE is much preferred.
I'll spent some personal time to see if I can work this out. I'll submit a patch if I do.
Thanks,
Ryan
In the Eclipse plugin, you have to build a working set (look in the PMD config in the project) that includes the packages you care about, and doesn't include the generated code packages.
Gee, your full rebuild took ONLY 4 hours? I have a project with 7500 source files, and a working set of only 935 files took about 13 hours.
Fortunately, my input on this problem was helpful to the plugin author, who will be releasing a new version Real Soon Now (after/combined with Tom releasing PMD 3.7) that should be a big help for this problem. I don't yet know how much it will help.
Well, I stopped after 4 hours. It didn't finish.
Um, working sets sounds like a nice PITA on 16 projects and 100s of packages. :) No thanks, I'll hack PMD to have a simple regex filter on file names specified in the ruleset files before I push that onto my developers. Then at least we'll be able to manage it centrally and uniformly.
I'm most concerned about the speed at this time. It's just insanely slow. My initial examinations make me think it's an issue with the overhead of the sheer number of Iterator instances produced by the DocumentNavigator for Jaxen. I'm gonna have to play around some and see what I can find.
Ryan
Hi Ryan -
Hm... I'd be suprised if Jaxen were the bottleneck... I mean, what happens if you run PMD on your code from the command line? Try running it from the command line with the -debug flag and see how it goes; it should be pretty snappy:
./pmd.sh /path/to/your/src/ text unusedcode -debug
Yours,
Tom
Using PMD? Get the book! http://pmdapplied.com/
Hi Tom,
I ran the ruleset you provided on the code in my workspace from the command line and it took just under 3 minutes. Which is rather quite nice, considering all the file parsing and etc.
Now, when I ran a ruleset containing the rules we would like to use (some 130 rules imported from the various OOTB PMD rules, no custom rules), it took about 90 minutes.
I infer two things from this:
1) There's definately something going on in the Eclipse environment to slow things down over what pure PMD is capable of doing.
2) Either because of the number of rules, or because of certain non-performant rules, PMD isn't scaling up very nicely with our particular ruleset.
I'd ideally like the PMD checks to take no more than 15 minutes. A full rebuild of our Eclipse workspace already takes 15 minutes, during which folks usually just do something else. I think I can justify the additional time given what PMD can do for our code quality.
I'll investigate our ruleset imports and see what I can find in the eclipse plugin. I'll work on our rule applicability to files problem after I get performance figured out.
Thanks,
Ryan
> it took just under 3 minutes
Cool, that sounds about right.
> it took about 90 minutes.
> [...] or because of certain non-performant rules
Hehe, yup, a bit longer. There's a benchmarking utility that comes with PMD that you can use to see which rules are the slowest; it's net.sourceforge.pmd.util.Benchmark:
http://pmd.sourceforge.net/xref/net/sourceforge/pmd/util/Benchmark.html
If you want, give that a whirl on one or two files and let me know which rules you are using that are taking the longest. Maybe there's some low-hanging fruit for optimization there. And of course all the other PMD users would benefit as well, which is nice...
Yours,
Tom
http://pmdapplied.com/
thnx folks... this discussion has been helpful...
i'm planning to implement PMD plugin for eclipse for our development team.. the # of files right now is small (a few hundreds), but it will grow over time in the next 6-10months to a few thousands. IF there are ANY optimizations done to the plugin to make it faster, how do I get to know about it?
thnx
-Faheem