I reopened the issue.
You are right. It does not work as expected. I will fix it and smoke test it.
1 person found this helpful
Are you using Maven or Ant?
If you use Maven, I will publish the snapshot artifacts with the fix in place.
Thanks for the quick reaction to the issue!
Currently there are a lot of places in the source code where suppressing is needed and a fix earlier than the next RC would make the FlexPMD reports defintely more meaningful. This would be really appreciated!
I invoke FlexPMD as a command-line tool. It is not integrated neither in Ant script nor Maven.
A few remarks to the possible fix:
1. Please make it somehow clear what the exact syntax is. In the bug I mentioned 4 ways to suppress a violation but I still don't know which is the right one. Probably all are wrong.
2. Suppressing by // NO PMD <RuleName> must not lead to suppressing all violations in case the <RuleName> doesn't match existing rule name. This is important because in case a rule name changes from a version to version or the developer enters wrong rule name they should not get suppressing for all violations. This would happen silently to them and it may lead to hiding other problems. In case it is a wrong rule name then nothing should be suppressed.
3. FlexPMD should trace during parsing what exactly gets suppressed and at which line number. This will keep developers and the tool on the same page.
Thanks a lot for your hard work!
1. The four ways you mentioned are now working. They were supposed to work in RC5, but it did not as you noticed. It is now fixed and unit-tested against trunk. It will be in the next release which will happen soon.
2. That's the way it is now working.
3. Good idea. I will add it.
Thanks again for your report.