We already have a PmdAnalysis class that serves as a programatic (non-CLI) entry point for PMD. This allows, the CLI, ANT, IDEs and other tools to trigger an analysis in an agnostic way.
We don't have anything equivalent for CPD, with the CPD, CPDConfiguration and CPDCommandLineInterface all mingled and dirty with CLI specific things (ie: the CPDConfiguration actually has the JCommander annotations).
What we would need to do:
I've a local branch where I've already started working on some of these items.
We already have a
PmdAnalysisclass that serves as a programatic (non-CLI) entry point for PMD. This allows, the CLI, ANT, IDEs and other tools to trigger an analysis in an agnostic way.We don't have anything equivalent for CPD, with the
CPD,CPDConfigurationandCPDCommandLineInterfaceall mingled and dirty with CLI specific things (ie: theCPDConfigurationactually has the JCommander annotations).What we would need to do:
CPDConfigurationinto a pure "analysis configuration" class, equivalent toPMDConfiguration. Is there anyway to "deprecate" the annotations in PMD 6 beyond a javadoc notice?AbstractConfigurationFileCollectorto accept any kind of configuration, either for PMD or CPDFileCollectordepends onLanguageDiscovererwhich is PMD-specific (CPD and PMD Language classes are unrelated), CPD on the other hand uses aFileExtensionFilter).CpdAnalysisclass in the same shape asPmdAnalysis. There may be an opportunity here to have a shared interface, but I'm not sure if this would be worth it.CpdAnalysisintoCPDto retain behavior, and explicitly stateCpdAnalysisto be the replacement for the already deprecatedCPD.I've a local branch where I've already started working on some of these items.