Add support for custom PMD jars

[Kevin Poorman]

I’m probably missing this, but how/where can i configure the pmd settings to include additional (non standard) .jars ? we have a few rules we’ve implemented that are in jars under <projectRoot>/pmd/*.jar and our ruleset needs these jars loaded as well.

‌

I’m filing this as a bug, because… well, I thought i could do this, but… can’t figure it out, and I figure a ‘bug’ will get me shot down with a ‘you idiot, click here’ faster than a Mig in Ukraine.

[Scott Wells]

No, you're not missing anything obvious. Because of how IC2 executes PMD in-process using a custom classloader, it's very specific about the jars that it loads to avoid potential conflicts/collisions with those already used by the IDE itself. I can certainly see a use case for being able to register additional jars with that process, though. I'll convert this into an enhancement request for just that functionality.

[Kevin Poorman]

Thanks Scott.

Trying to drive adoption of IC/Intellij here, and this is a blocker for us.

[Scott Wells]

Kevin, where are these custom jars located? Are they found under the PMD distribution directory? Under the project directory? Somewhere else? Trying to figure out a good way to allow the user to specify the additional jars in the PMD Salesforce inspection configuration while also preventing that config from becoming inherently non-portable due to local machine-specific paths. If they’re found within the PMD distribution directory – and PMD is found via the execution path – that would do the trick, as would having them in the project directory, but obviously that doesn’t scale well for other obvious reasons. I’m assuming the former. Can you confirm?

[Kevin Poorman]

We store our jars in <project_root>/pmd/*

We’re considering also putting the pmd dist in that folder as well. We’ve a very large team, and dealing with ‘I don’t have that version-itis' is getting old. I’m open to better ideas though.

[Kevin Poorman]

Additionally, we store our ruleset.xml files in the same folder.

[Scott Wells]

Kevin, I'm attaching a build that is 2.3.0.2 with an enhancement to the PMD Salesforce code inspection to allow selection of an optional directory containing additional rule jars. You can install it by downloading (but not extracting) the archive and using Settings / Preferences | Plugins | Install plugin from disk (under the gear drop-down menu). Allow the IDE to restart, and then in the PMD Salesforce code inspection options, you'll see an Additional jars path field that you can use to select your <projectRoot>/pmd directory. Note that all jars in that directory will be used by the custom classloader used to execute PMD, so please take care that it doesn't include third-party jars that might conflict with the base IDE itself.

Let me know if that helps or not. I already have a build ready to go out tomorrow and don't plan to include this, but if it looks good -- or at least close -- I could probably get it into next week's build and give you access to a custom build that is 2.3.0.3 (tomorrow's build) with this enhancement so that you can continue to play with it in the interim.

[Kevin Poorman]

@scott I tried to find a way to ask this privately, but … no dice.

For ethical/legal reasons, can I get it in writing that it’s ok for me to give this .zip to the 4 members of my trial team? Happy to have them dig up their license codes, if that helps, but I suspect the version you posted still requires an active license? Legal just wants me to dot the i’s and cross t’s since this isn’t going through the ‘app store’

[Scott Wells]

Kevin, no issues at all. Any pre-release build that I attach to an issue here in Bitbucket is available for install by any user with an active license or trial. These are just pre-release builds that allow users to help confirm fixes for issues and/or enhancements in advance of including those changes in a release. They still have the exact same licensing restrictions and requirements as any official build.

Also note that you can always reach out to me directly via the Support email address listed here:

https://www.illuminatedcloud.com/support

That will allow you to ask questions privately if/when desired.

[Kevin Poorman]

@Scott Wells,

‌

So far the plugin loads just fine, and I can specify the jar file directory. However, I may have discovered a related issue. Our ruleset.xml file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<ruleset
    name="Main"
    xmlns="http://pmd.sourceforge.net/ruleset/2.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://pmd.sourceforge.net/ruleset/2.0.0 https://pmd.sourceforge.io/ruleset_2_0_0.xsd"
>
    <description>Main Ruleset</description>
    <rule ref="pmd/ruleset.xml" />
    <rule ref="pmd/BAH-Apex.xml" />
    <rule ref="pmd/BAH-Flow.xml" />
</ruleset>

‌

I’m getting this error (attached screen shot) that makes me think it’s not able to resolve the path, or unable to follow the ref links in the xml.

‌

‌

[Kevin Poorman]

‌

[Scott Wells]

Kevin, would it be possible to share these jars and ruleset so I could test directly against them? That would be the best way to get to the bottom of what’s going on as custom classloaders can be difficult to troubleshoot at best.

[Kevin Poorman]

@Scott Wells, apologies on the delayed response. We’re working through the necessary hoops to share our .jars of custom rules.

‌

[Scott Wells]

No hurry on my side as I’m actually updating IC2 for PMD 7 now. The Java interface has changed considerably and I’m not 100% sure that I’m going to be able to maintain a single Salesforce Apex inspection that’s compatible with both PMD 6 and PMD 7 even with some reflection wizardy. Simply saying that everyone has to move to PMD 7 is attractive, but at a minimum, the PMD AppExchange rules are currently compiled specifically against PMD 6 and won’t work. Are your custom rules built against PMD 6 or 7? I’m assuming 6 since 7 was just released. If so, you might also want to take a look at what might be involved in migrating them to PMD 7 since my guess is that’s where things are going. PMD 7 uses a new open source Apex parser that’s been updated for recent Apex grammar changes such as the null coalescing operator whereas PMD 6 has not and will not be updated for such changes.

[Kevin Poorman]

Our rules are currently built / rebuilt for both. We originally targeted 7, but backed them to 6.55, because we’re using the SF Sec scanner wrapper. As of last week, it now supports 7

[Scott Wells]

Regarding:

the SF Sec scanner wrapper. As of last week, it now supports 7

I’m definitely not seeing that as being the case, though let’s make sure that we’re talking about the same thing. I’m specifically talking about the PMD AppExchange rules that are installed via the Salesforce Code Analyzer plugin (@salesforce/sfdx-scanner). I’ve done a clean uninstall/reinstall to ensure that the latest version is installed:

Installing plugin @salesforce/sfdx-scanner@latest... installed v3.22.0
Successfully installed @salesforce/sfdx-scanner v3.22.0

$ sf plugins
@salesforce/sfdx-scanner 3.22.0

and the resulting jars are definitely still compiled against PMD 6 as trying to use them results in NoClassDefFoundError: net/sourceforge/pmd/lang/BaseLanguageModule which exists in PMD 6 but not PMD 7.

Are you perhaps talking about something else that’s been updated for PMD 7?

[Scott Wells]

Kevin, I’ve confirmed with Salesforce that Code Analyzer is not currently using PMD 7. You can see more details in #2537, and I’ll post new status there as available. I’m happy to take a look at your custom jars and ruleset once they’re provided, but at this point it’s likely that I’ll bundle changes to support them in the same release as the PMD 7 changes. The main reason I wouldn’t couple those is if Salesforce comes back and says that Code Analyer PMD 7 support is looking to be more distant than currently thought.

[Scott Wells]

Oh, and I found this regarding SCA and PMD 7:

https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/pmd-engine.html#scan-your-code-with-pmd-700-rc4

but that’s specifically using PMD 7 RC4 and not PMD 7 GA. PMD 7 RC4 actually had effectively the same Java API as PMD 6 and didn’t cause issues (not 100% true, but close). If you’re still building your own rules against RC4, I recommend updating them for GA as it has quite a large set of changes, though mostly Java package changes and not actually type interface changes.

[Scott Wells]

FYI, this Thursday I will be releasing an IC2 update that will support PMD 7…and only PMD 7. Once I have that release out, I’ll be happy to take a look at providing support for custom rule jars that are also PMD 7-compatible, though as before, I will likely need access to those jars and the associated ruleset to suss out any potential issues, especially if third-party libs also come into play in support for those jars.