Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Juan Martín Sotuyo Dodero
@jsotuyod
@mhmoran then you should just download a binary distribution of PMD and run it directly
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
Alexis SEGURA
@alexisgra
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 ! :)
Ullrich Hafner
@uhafner
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.
Alexis SEGURA
@alexisgra
Ok thanks I found the previous discussion. So I implemented a custom rule that calls the Metrics framework. Thank you and have a good continuation on your project ! :)
Saladoc
@Saladoc
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?
Andreas Dangel
@adangel
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
Andi Pabst
@andipabst
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!
Andreas Dangel
@adangel
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.
Saladoc
@Saladoc
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.
Andi Pabst
@andipabst
@adangel Oh, thats unfortunate! But thank you for your help!
Clément Fournier
@oowekyala
@Saladoc this TODO was added recently (in pmd/pmd#2021)
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
Artem
@KroArtem
@oowekyala , @adangel , hello, are there any estimates about 6.21 release? I just want to cleanup our project from pmd deprecations and eager to do it with latest release :)
Andreas Dangel
@adangel
Hi @KroArtem, I plan to release 6.21.0 today....
Artem
@KroArtem
Nice! There are some issues labeled with 6.21 and not closed/merged but I suspect they'll move to 6.22 then
Clément Fournier
@oowekyala
@KroArtem We're done with the release, see https://github.com/pmd/pmd/releases
Artem
@KroArtem
@oowekyala , thanks! Will have a look tomorrow
Artem
@KroArtem
Hello there! I'm trying to add maven-pmd-plugin instead of custom invocation from java-code. I've added my custom rulesets to configuration but whilst running verify goal plugin starts to visit rulesets and fails to load custom rules. Custom rules are in the same maven module as rulesets.
[INFO] --- maven-pmd-plugin:3.13.0:pmd (pmd) @ test_utils ---
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[ERROR] Error instantiating a rule
java.lang.ClassNotFoundException: checkstyle.mypackage.TestMustNotImportJavaliteRule
If any info is required, I'd be glad to share as it's not clear what to do :)
Artem
@KroArtem
The structure is the following:
-- root pom.xml where pmd plugin is defined and configured
   \module a
   \module b
...
   \module c with rulesets and rules
Andreas Dangel
@adangel
module c needs to be on the plugin's classpath. Usually, a separate/independent project is used (often called "build-tools") - see https://maven.apache.org/plugins/maven-pmd-plugin/examples/multi-module-config.html for an example
Artem
@KroArtem
@adangel , is it important to be separate module without any additional logic? We have test_utils module that contains this or that stuff, it has rulesets and rules. I've defined a dependency in root pom as in an article you've attached but still no luck. Are there by change any ideas that can help me? :) Here is what I've added in root pom: https://pastebin.com/7i9BiaJR
${project.version} is a 1.0-SNAPSHOT as we don't have real versioning (yet)
Artem
@KroArtem
hm, I think I just forgot to install test_utils module to .m2, currently something seems to be working, at least it loads without any errors/exceptions :)
Artem
@KroArtem
I have two more questions:
1) Is there any reason to cleanup custom rules from deprecations? I've updated to 6.21 and see some deprecated usages both in rules and in a way we call PMD programmatically. Is it worth doing or is 7.0 somewhere near?
2) The other question is about incremental cache. Recently we've switched to gitlab ci and are running pipelines there. However, we check only changed files by getting list of these files against master. I'm planning to do the following: after merging to master a job checks the project and gets up-to-date state. This cache is saved in gitlab ci artifacts and is available for another runs. This way we'll eliminate our crutches that help to check only changed files. Another branch uses the cache, somehow (I don't know how PMD does this) understands what files should be checked and voila! It's not clear, though, what will happen if branchA doesn't have master?
Also another question got to my mind, wouldn't the cache be overriden by these runs... I mean, we need to get the information from cache but we don't need to update its state
Andreas Dangel
@adangel
1) It might help - the more you can do now, the less you need to do later when switching to 7.0
2) I'm not sure, I understand this: "if branchA doesn't have master?"
PMD itself checks, whether files have been modified by using a checksum. If the file has not been modified, the rules are not executed, but the cached violations are reported. If the file has been modified, then the rules are executed and found violations are reported + added to the cache. In the end, a updated analysis cache file is written to disk.
So, you can mix branches and master, it should work. PMD will run the rules for any new or modified file. In the end, the cache file is just a file (some java serialized data), that you can copy/move around.
When you are using maven and m-pmd-p, then by default, the cache file is inside the target directory. This means, you should configure the plugin, to store it somewhere else, so that it won't be cleaned if you run mvn clean install. See property https://maven.apache.org/plugins/maven-pmd-plugin/pmd-mojo.html#analysisCacheLocation
Andreas Dangel
@adangel
Maybe this is something we can explain better on https://pmd.github.io/latest/pmd_userdocs_incremental_analysis.html ?
Artem
@KroArtem
1) Thanks, I've been working on cleaning out the code that calls PMD right now. Wondering why do we create Renderers and do PMD.processFiles on each file instead of processing all files altogether.. Seems like this should be optimized.
2) The idea was that I have master with up-to-date cache and branchA that is behind master. The question was How would PMD understand which files would be processed? I have read https://pmd.github.io/latest/pmd_userdocs_incremental_analysis.html before asking it here and do believe this topic could be explained more verbose (you did it better than those article)
Artem
@KroArtem

@adangel , hello, just wanted to ask, I've had such a piece of code:

public String a(String one, String two) {
        return "test";
    }
public String aa(String one, String two) {
        List<String> strings = new ArrayList<>();
->>        return a("one", strings.isEmpty() ? null : "two");
    }

PMD says there is violation of https://pmd.github.io/pmd-6.20.0/pmd_rules_java_errorprone.html#nullassignment

From my point of view, it looks like a false positive. Just wanted to double-check
Juan Martín Sotuyo Dodero
@jsotuyod
@KroArtem yeap, that's a false positive, please open an issue in Github
as for your questions…
1) I'm unsure of what your code looks like, but yes, a single call to processFiles should suffice (that's what PMD itself does)
Artem
@KroArtem
@jsotuyod , thanks, will create an issue in the evening.
I've almost finished switching our code to a single call (There was some additional logic that's why, at least I think so, it was previously done linearly)
Juan Martín Sotuyo Dodero
@jsotuyod
2) as Andreas said, PMD will compute a checksum on each file. You can think of the cache as a Map where the filepath is used as the key, and the violations found in previous runs are the value. For each file being analyzed, we look it up in the map (see if it's new or not), and if not, we compute a checksum and see if the file was modified since the last run or not. If not changed, we don't even look at the file and simply keep the saved violations. If it's changed, we parse it again and rerun all rules for that single file. After we are done, we update the cache. So basically, PMD will only analyze files that changed between runs. If your previous run was on branch A and then you run on branch B using the same cache file, it will only look at files that are different between the 2 branches.
Artem
@KroArtem
@jsotuyod , thanks for more verbose explanation! I was thinking, though, about an option for incremental cache. Right now in case we want to introduce it, we need to fix all violations and then use in in our pipeline process. (So that the build will be always green). Some analyzers have an option called like Mass Suppression that suppresses old violations and warns only about new ones. As far as I understand there is no such possibility in current implementation?
Andreas Dangel
@adangel
No, there is currently no feature like that built-in in PMD. The cache is the closest - in that it is the only feature, that considers historic data. I think, that would be an interesting feature, e.g. run PMD once and produce sth. like a "violation snapshot" and then use this snapshot in later runs. The simplest (and naive) implementation would be, to just look at the line numbers of the violation to determine, whether a violation is new or already existing.
I guess, you could implement something like this outside of PMD by using the XML report format and do a diff between a previously recorded report ("the snapshot") and the new one.
Ullrich Hafner
@uhafner
How do you run your pipeline? If you are using Jenkins then you can use the Warnings plugin to highlight and select only new PMD warnings. It already has such algorithm implemented that detects new warnings between two different builds.
Andreas Dangel
@adangel
@KroArtem I've written up the documentation now: pmd/pmd#2370 - and I remembered a similar question earlier: see pmd/pmd#2063 - atm you can only share the cache, if the full absolute path names stay the same
Artem
@KroArtem

@adangel , that is awesome, thanks! One more question:

Also note, that if the branch uses a different dependencies, the auxclasspath is different on both
classes, which invalidates the cache completely.

As far as I understand, updating any maven dependency in a project will invalidate the cache, right?

It doesn't sound like a problem. The main thing is to fix all existing warnings before integrating cache :)
Andreas Dangel
@adangel

As far as I understand, updating any maven dependency in a project will invalidate the cache, right?

That's correct.

Artem
@KroArtem
thanks! Returned from vacation and finished small refactoring. Now PMD is called for all files instead of calling one by one. Found an issue in our utility class that was gathering all unique ids in the project (now PMD is launched in several threads, as far as I understand. This requires utility class that is called in a rule to be synchronized). Regarding speed, it seems like it's about 300-400% faster than it was before :smiley:
Harika
@Harika16689493_twitter
Could anyone please tell me how to write custom rules for Visual force Pages in Apex PMD .