bare in mind, that is only needed to build the docs / site; not the actual PMD binary
you can probably just skip those tasks / choose a different maven target
so not building implies not having the documentation locally, does that imply I can find it elsewhere ?
so what is the distinction between target and src rulesets
under src are the originals
you probably care about neither
already contains all rulesets, and you can reference them directly by name
ie:
-R rulesets/java/quickstart.xml
it will load it from the internal resources
if you just want to run PMD against some sources, you don't actually need to build it manually
https://pmd.github.io/ -> under quickstart you can see how to download and use the PMD binary for each OS
extra details on Command line arguments can be found here: https://pmd.github.io/pmd-6.17.0/pmd_userdocs_cli_reference.html
and information on how to tailor a set of rules for your particular needs and likes is detailed here: https://pmd.github.io/pmd-6.17.0/pmd_userdocs_making_rulesets.html
as for the complete catalogue of available rules, you can check the Java rules here: https://pmd.github.io/pmd-6.17.0/pmd_rules_java.html
and Javascript here: https://pmd.github.io/pmd-6.17.0/pmd_rules_ecmascript.html
/usr/local/src/pmd.github.io/pmd-dist/target/classes/scripts/run.sh: line 73: cd: /usr/local/src/pmd.github.io/pmd-dist/target/classes/scripts/../lib: No such file or directory
Error: Could not find or load main class net.sourceforge.pmd.PMD
Caused by: java.lang.ClassNotFoundException: net.sourceforge.pmd.PMD
Error: Could not find or load main class net.sourceforge.pmd.PMD
Caused by: java.lang.ClassNotFoundException: net.sourceforge.pmd.PMD
@mhmoran That script expects a directory structure that matches that of the distribution archive. Here it's just in a temporary location where maven copies resources before packaging them, so the structure doesn't match. If you really want to build a distribution locally, use
mvn package or mvn install from the project root directory and then use the zip in pmd-dist/target/pmd-bin-<version>.zip (but not the stuff in target/classes directly). But really the easiest way to install PMD is to not fiddle with the sources and to download a prebuilt archive from here, and to install it somewhere by just unzipping it.
follow the quickstart from the web
and once you get that running, you can dive into more advanced usage
extra details on Command line arguments can be found here: https://pmd.github.io/pmd-6.17.0/pmd_userdocs_cli_reference.html
and information on how to tailor a set of rules for your particular needs and likes is detailed here: https://pmd.github.io/pmd-6.17.0/pmd_userdocs_making_rulesets.html
as for the complete catalogue of available rules, you can check the Java rules here: https://pmd.github.io/pmd-6.17.0/pmd_rules_java.html
and Javascript here: https://pmd.github.io/pmd-6.17.0/pmd_rules_ecmascript.html
and information on how to tailor a set of rules for your particular needs and likes is detailed here: https://pmd.github.io/pmd-6.17.0/pmd_userdocs_making_rulesets.html
as for the complete catalogue of available rules, you can check the Java rules here: https://pmd.github.io/pmd-6.17.0/pmd_rules_java.html
and Javascript here: https://pmd.github.io/pmd-6.17.0/pmd_rules_ecmascript.html
Hello, I was wondering if it was possible to retrieve java code metrics (cf: https://pmd.github.io/pmd-6.17.0/pmd_java_metrics_index.html) via the CLI in the 6.17 or previous version ? Or am I required to create my own rules using the metric framework ? Thank you ! :)
We discussed that topic a couple of weeks ago (in May actually, is there a way to link to previous posts in Gitter?). It is not possible yet. One of my students will start working on that topic in his thesis. The general idea is to have a tool that uses PMD to extract those metrics into a file which then can be read by other tools. These metrics then can be consumed by Jenkins warnings plugin to present those metrics along with the PMD warnings.
Hey I'm trying to work on pmd/pmd#659. I figured that in order to properly support it I'd need to port the rule over to its own class instead of using the old XPath version. Is there any good place to read up on the whole AST implementation or should I continue piecing together how it works from other tests and the trial, error and debugger?
Hi, thanks for working on PMD. I'd suggest to use the designer (https://pmd.github.io/latest/pmd_userdocs_extending_designer_reference.html) to have a look a the AST structure and the available attributes. In your IDE, you can use autocomplete to navigate the nodes (like
findChildrenOfType(...) and findDescendantsOfType(...). See also https://pmd.github.io/latest/pmd_userdocs_extending_writing_pmd_rules.html
Hi, I added a pull request for calculating the Class Fan Out Metric in PMD (pmd/pmd#20769). This is the number of classes used by a certain class. Now I would also like to add the opposite, the Fan In (which classes are using the considered class). But I think this can not be computed by looking at only one class at a time, like the other metrics. Could you please point me in a direction on how this could be implemented? Thank you very much!
Hi, I'm afraid that's not possible with PMD 6. What we would need here is something like a "multifile analysis". You can currently write a rule, that visits every file and you can collect and share data via
RuleContext#setAttribute(String, Object). But we are missing a final call at the end of the analysis of all files, where you could analyse the collected data and report violations based on this. It might be part of PMD 7, but that's not sure yet.
While reading through some code to find the best way on how to iterate over a node's children I stumbled on https://github.com/pmd/pmd/blob/591cfc0a51febd8aa9869277f5c16914798c97e1/pmd-core/src/main/java/net/sourceforge/pmd/lang/ast/Node.java#L118 which seems like a legacy to do task or something? Maybe someone who is more familiar than the code will want to make sure that task is reflected somewhere more suitable.
It's scheduled for 7.0.0 since this is an API breaking change (eg would break the designer), and requires all supported language implementations to be aligned on the convention