How best to support direct Java-based integration with both PMD 6 and PM7 in a single distribution

[SCWells72]

Hi, folks. My product has included a direct Java-based integration with PMD for a while now. The interface has changed quite a bit in PMD 7 vs. PMD 6, though, with several key classes/interfaces being moved into different packaging. This is making it very difficult to have a single distribution of my product that works against both PMD 6 and PMD 7. I'm wondering if there are any recommendations for getting this to work that I've perhaps overlooked.

To be specific, I have compile-time references to the following types that have been repackaged across major versions:

• net.sourceforge.pmd.Rule => net.sourceforge.pmd.lang.rule.Rule
• net.sourceforge.pmd.RulePriority => net.sourceforge.pmd.lang.rule.RulePriority
• net.sourceforge.pmd.RuleSet => net.sourceforge.pmd.lang.rule.RuleSet
• net.sourceforge.pmd.RuleSetLoadException => net.sourceforge.pmd.lang.rule.RuleSetLoadException
• net.sourceforge.pmd.RuleSetLoader => net.sourceforge.pmd.lang.rule.RuleSetLoader
• net.sourceforge.pmd.RuleSetReference => net.sourceforge.pmd.lang.rule.RuleSetReference
• net.sourceforge.pmd.Report => net.sourceforge.pmd.reporting.Report
• net.sourceforge.pmd.RuleViolation => net.sourceforge.pmd.reporting.RuleViolation
• net.sourceforge.pmd.lang.vf.VfLanguageModule => net.sourceforge.pmd.lang.visualforce.VfLanguageModule
• net.sourceforge.pmd.util.log.MessageReporter => net.sourceforge.pmd.util.log.PmdReporter

It seems that if there were backward-compatible stubs in place for PMD 6 types like these that were simple extensions of the same type in the new location (or in the case of MessageReporter/PmdReporter, new name as well), that should allow a single implementation to work against both versions. I know that's pretty nasty, though, so I'm hoping there might be some other recommendation on how to handle this situation. Thoughts?

[jsotuyod]

That is exactly what you may need. We already provide some limited implementation of this on the pmd-compat6 module, but bare in mind, that, as stated in the PMD 7.0.0 release notes…

It's not decided yet, whether we will keep updating it, after PMD 7 is finally released.

As long as the classes you are using are part of the PMD 7 public API, normal backward compatibility is to be expected during PMD 7's lifetime, with no guarantees for an eventual PMD 8 release. If however, you are using any non-public APIs, you may face any kind of breaking changes during minor PMD 7 releases.

[SCWells72]

Thanks for the response, @jsotuyod. I'm glad to hear that such a thing was considered, but it does seem to be missing some of the things I'm referencing, in particular RuleSet, RuleSetReference, and MessageReporter (ignoring the language-specific VfLanguageModule). Also, unless I'm misunderstanding, it seems that it would be required for the PMD 7 distribution to include that jar for things built against it to work properly against that version, correct? Because if I bundled that jar in my own product to ensure that it's present, those stubs could eclipse the real types from PMD 6. Or are those stubs actually more than just stubs and can also be used safely against a PMD 6 distribution?

Apologies if I'm misunderstanding. Just trying to figure out how to get to the goal of working against both 6 and 7 if possible.

[jsotuyod]

The classes covered there are exclusively limited to those needed to ensure the PMD Maven plugin would work with PMD 7 until a new release is made, due to a chicken and egg problem, of the plugin compiling against classes in PMD itself. So yes, expect plenty more to be missing.

And again, classes such as RuleSetReference are now internal, and subject to change at any given time.

That approach will only work with PMD 7, for code compiled against PMD 6. The classes would collide and not allow for that and PMD 6 to coexist. You can move around this by manually setting up a UrlClassLoader with either PMD 6 or 7 + compat modules at runtime for a specific run.

[SCWells72]

Got it. Makes sense. And for context, I'm using RuleSetReference to get access to the original ruleset filename because I provide several contextual actions for reported problems relating to the original ruleset file, specifically viewing the rule that produced the reported problem, disabling that rule (via XML comment), and changing the priority of that rule. Is there another way to get the original ruleset file information that's not considered internal? Oh, and again, thanks for all of the info you're providing here...