Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/pmd/pmd/issues/4204 below:

[core] Provide a CpdAnalysis class as a programmatic entry point into CPD · Issue #4204 · pmd/pmd · GitHub

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:

• Explicitly convert CPDConfiguration into a pure "analysis configuration" class, equivalent to PMDConfiguration. Is there anyway to "deprecate" the annotations in PMD 6 beyond a javadoc notice?
• Consolidate how PMD / CPD collect analysis files
  • Since we are aligning how PMD / CPD manage analysis sources, it may make sense to pull up those attributes and methods to AbstractConfiguration
  • Extend FileCollector to accept any kind of configuration, either for PMD or CPD
    • Tricky part: FileCollector depends on LanguageDiscoverer which is PMD-specific (CPD and PMD Language classes are unrelated), CPD on the other hand uses a FileExtensionFilter).
• Implement a CpdAnalysis class in the same shape as PmdAnalysis. There may be an opportunity here to have a shared interface, but I'm not sure if this would be worth it.
• Hook CpdAnalysis into CPD to retain behavior, and explicitly state CpdAnalysis to be the replacement for the already deprecated CPD.

I've a local branch where I've already started working on some of these items.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4