For this to work, a Rule/RuleSet being added by Reference must have a file name associated with it. This information will be associated with the RuleSet when created by the RuleSetFactory using the APIs which provide file names/resources. If a raw InputStream form is used, then the file name will need to be manually set.
git-svn-id: https://pmd.svn.sourceforge.net/svnroot/pmd/trunk@5777 51baf565-9d33-0410-a72c-fc3788e3496d
Code cleaning, switching inheritance to AbstractJavaRule.
Adding proper documentation to the new rule's properties.
git-svn-id: https://pmd.svn.sourceforge.net/svnroot/pmd/trunk@5774 51baf565-9d33-0410-a72c-fc3788e3496d
The essence of this change is to add the RuleReference and RuleSetReference classes, which contain the details that were previously missing from the runtime representation which are available in the XML, specifically the details about usage of Rules by reference. This now means that XML <-> runtime RuleSet are interchangeable, a modification in one can be reflected in the other. PMD IDE plugins which support Rule editing can now use the core PMD classes and standard XML serialization, instead of implementing custom value
objects and serialization mechanisms.
The RuleReference class is essentially a wrapping around an existing Rule instance. It is the RuleReference which is directly contained in the RuleSet now, instead of the original Rule instance. Any code which uses instanceof checks on Rule instances will have problem when encountering a RuleReference. Thankfully this is a rare occurrence, only the RuleChain code seemed to have to be tweaked to deal with this. Even so, I wouldn't be surprised if something turns up that needs to be addressed.
git-svn-id: https://pmd.svn.sourceforge.net/svnroot/pmd/trunk@5764 51baf565-9d33-0410-a72c-fc3788e3496d
I already implemented this 6 month ago but i didn't have the commit it. Since the designer class has been revised,my modifications, still on the patch tracker, became obsolete.
git-svn-id: https://pmd.svn.sourceforge.net/svnroot/pmd/trunk@5760 51baf565-9d33-0410-a72c-fc3788e3496d
This is an incremental cleanup. The real cleanup is the unify all these Language specific concepts across the entire PMD code base. Specifically, the CPD Language stuff, SourceType, SourceTypeHandler, TargetJDK, Parsers, AST nodes, and anything else I missed. That change will wait until we're ready to do a major PMD internal refactoring.
git-svn-id: https://pmd.svn.sourceforge.net/svnroot/pmd/trunk@5755 51baf565-9d33-0410-a72c-fc3788e3496d
- AbstractClassWithoutAnyMethod
- TooFewBranchesForASwitchStatement
Also, i disabled rule and test about the HttpFilterCounter rule, that is still buggy...
git-svn-id: https://pmd.svn.sourceforge.net/svnroot/pmd/trunk@5747 51baf565-9d33-0410-a72c-fc3788e3496d
I've begin to implements such a rule (well, more of a generic rule). I'll try to finish tonight. I also added a test case.
Thanks Ryan for this, somehow small, but quite usefull upgrade ;) !
git-svn-id: https://pmd.svn.sourceforge.net/svnroot/pmd/trunk@5740 51baf565-9d33-0410-a72c-fc3788e3496d
Added Rule.start() and Rule.end() for pre/post processing hooks. Added shared attributes to RuleContext for storage of shared state across all Rule.apply() invocations. Essentially a rule could on (1) Rule.start() does any necessary setup on RuleContext attributes, (2) Rule.apply() accumulates results in RuleContext attributes (must be thread-safe!), (3) Rule.end() gets/removes RuleContext attributes to produce any necessary violations.
Inane example:
package net.sourceforge.pmd.rules;
import java.util.concurrent.atomic.AtomicLong;
import net.sourceforge.pmd.AbstractJavaRule;
import net.sourceforge.pmd.RuleContext;
import net.sourceforge.pmd.ast.ASTExpression;
public class CountRule extends AbstractJavaRule {
private static final String COUNT = "count";
@Override
public void start(RuleContext ctx) {
ctx.setAttribute(COUNT, new AtomicLong());
super.start(ctx);
}
@Override
public Object visit(ASTExpression node, Object data) {
// How many Expression nodes are there in all files parsed! I must know!
RuleContext ctx = (RuleContext)data;
AtomicLong total = (AtomicLong)ctx.getAttribute(COUNT);
total.incrementAndGet();
return super.visit(node, data);
}
@Override
public void end(RuleContext ctx) {
AtomicLong total = (AtomicLong)ctx.getAttribute(COUNT);
addViolation(ctx, null, new Object[] { total });
ctx.removeAttribute(COUNT);
super.start(ctx);
}
}
git-svn-id: https://pmd.svn.sourceforge.net/svnroot/pmd/trunk@5739 51baf565-9d33-0410-a72c-fc3788e3496d
Long term goal is to support additional languages beyond Java. Organized like so:
pmd.AbstractRule // Core Rule implementation
pmd.XPathRule // Core XPath Rule implementation
pmd.java.AbstractJavaRule // Java specific Rule implementation
pmd.jsp.AbstractJspRule // JSP specific Rule implementation
pmd.xxx.AbstractXxxRule // Language XXX specific Rule implementation
...
This is a start, there's a much larger reorganizing effort to get things in sync. Additional work is needed on generalizing XPathRule.
git-svn-id: https://pmd.svn.sourceforge.net/svnroot/pmd/trunk@5734 51baf565-9d33-0410-a72c-fc3788e3496d
